Q: If the private key never leaves the device, how does it sync from one device to another?
A: On syncing platforms from Apple/Google/Microsoft and from 1Password, trusted devices sync from one trusted device to another as an E2EE blob (i.e., data that's end-to-end encrypted). The precise behavior of this blob will vary from platform to platform, and in the coming months, I think it’s incumbent on syncing services to document the encryption they use to protect the passkey data. But again, if you trust any cloud service to sync passwords now, there’s no reason not to trust it to sync passkeys as well.
Q: What happens if I lose the device or devices storing my passkey? How will I ever get back into my account?
A: For people who use multiple devices to log in to an account, the key will live on there. If your lost device was the only one storing the passkey or if you lose all your devices, you can simply log in using your password, the way you always have. If you have recovery codes for the account, you can also regain access through them.
Q: So I (or possibly an adversary) can still log in to my account with a password or a recovery code? How, then, are passkeys safer?
A: The short answer is that passkeys are immune to credential phishing since there’s nothing for a user to enter into a malicious site or to provide to a phisher trying to trick you into providing your credentials (say, in a phone call pretending to come from an admin). Passkeys also have two-factor authentication built into the flow.
The longer answer is that the fallback to passwords or recovery codes does introduce some vulnerability, at least theoretically. If an attacker can trick you into logging in to a phishing site with your password or passcode, or to provide either of those in a phone call (this happens more than you may think), all bets are off. This isn’t true just for bypassing passkey security, though; it's true for the security of any form of 2FA.
At the moment, the password fallback is pretty much universal. The only accounts I have (and I have hundreds) that allow me to restrict the use of recovery codes when logging in are my Gmail accounts—and then only because I’m enrolled in Google’s Advanced Protection Program.
Q: WebAuthn and the other FIDO specs describe a pretty complex system with lots of moving parts. The more complex something is, the more likely there are mistakes. How safe are passkeys, really? Is there a net gain after considering the risk of a bad implementation?
A: There’s no way to guarantee that a company allowing users to log in with a passkey or a service that syncs that passkey won’t slip up. But that risk already exists to a large extent with password-based authentication systems, and once you bolt on OAuth or third-party authentication services like Okta, you probably have an authentication process that’s as complex as passkeys (or even more so).
More to the point, the specs that make passkeys work have been hammered out by hundreds if not thousands of engineers from scores of tech and government organizations across the industry. Many people are familiar with the adage "don’t roll your own encryption." The specs behind passkeys are anything but self-rolled. Passkeys aren’t something developed by a handful of large players who have ulterior motives. Organizations across the board believe passkeys have the potential to make account takeovers much harder and do so with much less user friction and less risk of being locked out of an account.
Q: The Bluetooth requirement is a "hard no" for me. I don’t want the hassle of having to disconnect it first from one device. The communication protocol is complete garbage and should never be part of any authentication scheme. Plus, I don’t want to go search for my phone in the other room every time I want to log in to my account.
A: There’s a lot to unpack here. First, the use of Bluetooth is an option, not a requirement. Bluetooth only comes into play when performing cross-device authentication—using a device (such as a phone) that has already logged in to the account to authenticate a device (such as a PC) to the same account. During this process, the phone and the PC must have Bluetooth turned on, but they need not be paired. This is to prove that the two devices are close to each other. If you hate Bluetooth, simply opt to log in new devices using a password or another method that doesn’t involve cross-device authentication.
I have been testing passkeys for more than two months using an iPhone 13, a MacBook Air, a ninth-generation iPad, a Pixel 7, and a Windows 10 ThinkPad. I have performed literally hundreds of logins. While doing cross-device authentication, I have had exactly zero instances of the two devices being unable to connect over Bluetooth.
The sole purpose of the Bluetooth connection is to ensure the two devices are within close proximity. No shared secrets or sensitive data travel between the devices.
Q: What if an adversary gets access to my unlocked device storing one of my passkeys?
A: The adversary would still have to unlock the device when logging in to your account with one of your passkeys.
Q: What if Google or another site deprecates passwords and allows logging in only with passkeys?
A: This seems extremely unlikely for a bunch of reasons that are mostly logistical. No companies have said they plan to deprecate passwords. If you still think a company is going to do this and passkeys are a non starter for you, you should move off the platform as soon as practical. If you're like most people, the off-boarding will be labor intensive. During this lengthy process, consider turning on passkeys to make things easier. The reason: If a site deprecates passwords (again, a massive, massive if) it won't happen because you did or did not turn on a passkey. It will have happened either way. The passkey will only make the transfer easier to do.
Q: I don't like the idea of passcodes making mugging people too user friendly: eg hit them with a pipe, take their phone, point it at their face to unlock, and you can now run off with access to their bank accounts.
A: If you have your device set so it unlocks only with a passcode or PIN, you (or a mugger) won't be able to use passkeys with a face or fingerprint scan.
The article claims there is ‘nothing to lose’ by trying out passkeys. What about loss of time, the stress of being locked out of your accounts because of bugs, or something you misunderstood?
A: If after reading this post and previous Ars coverage, you feel this level of worry, you should skip passcodes, at least for now.
Q: Why is Ars pushing passkeys so hard?
A: Based on conversations I’ve had with numerous people specializing in account authentication, I see great promise in passkeys because I think they will be easier and, on the whole, more secure once people develop the same kind of muscle memory they have now with passwords. Only time will tell, but I see no reason that people, including skeptics, shouldn’t at least try them. There's nothing to lose. If you don’t like passkeys, you can delete them (with the exception of passkeys Google automatically created on Android devices) and fall back to passwords at any time with no penalty.
Update with new questions:
Q. Is there an open source implementation of the sync server I can use to run my own instance?
A: Nothing stops anyone from building something like this. Android makes it easy to plug an implementation right into Android using Google's new credential manager APIs.
Q: Can you back up your passkeys?
A: Not yet. But per this note from an engineer elbow-deep into the implementation of passkeys, import/export capabilities across devices and passkey managers are in the works.
