Passkeys may not be for you, but they are safe and easy—here’s why

My recent feature on passkeys attracted significant interest, and a number of the 1,100-plus comments raised questions about how the passkey system actually works and if it can be trusted. In response, I've put together this list of frequently asked questions to dispel a few myths and shed some light on what we know—and don't know—about passkeys. This FAQ will be updated from time to answer additional questions of merit, so check back regularly. This author will not be monitoring or responding to comments going forward but can still be contacted through email.

 

Q: I don’t trust Google. Why should I use passkeys?

 

A: If you don’t use Google, then Google passkeys aren’t for you. If you don’t use Apple or Microsoft products, the situation is similar. The original article was aimed at the hundreds of millions of people who do use these major platforms (even if grudgingly).

 

That said, passkey usage is quickly expanding beyond the major tech players. Within a month or two, for instance, 1Password and other third parties will support passkey syncing that will populate the credential to all your trusted devices. While Google is further along than any other service in allowing logins with passkeys, new services allow users to log in to their accounts with passkeys just about every week. In short order, you can use passkeys even if you don’t trust Google, Apple, or Microsoft.

 

Q: I don’t trust any company to sync my login credentials; I only keep them stored on my local devices. Why would I ever use passkeys?

 

A: Even if you don’t trust any cloud service to sync your login credentials, the FIDO specs allow for something called single-device passkeys. As the name suggests, these passkeys work on a single device and aren’t synced through any service. Single-device passkeys are typically created using a FIDO2 security key, such as a Yubikey.

 

However, if you’re syncing passwords through a browser, a password manager, iCloud Keychain, or one of the Microsoft or Google equivalents, be aware that you are already trusting a cloud service to sync your credentials. If you don’t trust cloud services to sync passkeys, you shouldn’t trust them to sync your passwords, either.

 

Q: It seems incredibly risky to sync passkeys. Why should I trust syncing from any service?

 

A: Currently, the FIDO specifications call for syncing with end-to-end encryption, which by definition means nothing other than one of the trusted end-user devices has access to the private key in unencrypted (that is, usable) form. The specs don't currently mandate a baseline for this E2EE. Apple’s syncing mechanism, for instance, relies on the same end-to-end encryption that iCloud Keychain already uses for password syncing. Apple has documented the design of this service in great detail here, here, here, here, and here. Independent security experts have yet to report any discrepancies in Apple’s claim that it lacks the means to unlock the credentials stored in the iCloud Keychain.

 

iCloud is a fundamental security feature. The onus should be on the company claiming it's safe to proof said safety [sic], not on others to disproof [sic] it.

 

A: As noted earlier, if you don't trust Apple or any other company offering syncing, consider using a single-site passkey. If you don't trust Apple or any other company offering syncing and you don't want to use a single-site passkey, passkeys aren't for you, and there's not much point reading future Ars articles on this topic. Just remember that if you don't trust iCloud et al. to sync your passkeys, you shouldn't trust them to sync passkeys or any other sensitive data.

 

Q: What about the other syncing services? Where’s their documentation?

 

A: Google has documentation here. 1Password has documentation on the infrastructure that it uses to sync passwords (here and here). Again, if you already trust any cloud-based password syncing platform, it's a little late to ask for documentation now. There’s little, if any, added risk to sync passkeys as well.

 

Q: Wasn't there a recent article about new macOS malware that could steal iCloud Keychain items?

 

A: This may be a reference to MacStealer, malware that was recently advertised in underground crime forums. There are no reports of MacStealer being used in the wild, and there’s no confirmation that the malware even exists. We only know of ads claiming that such malware exists.

 

That said, the ad hawking MacStealer says it’s in early beta and comes in the form of a standard DMG file that must be manually installed on a Mac. The DMG file is not digitally signed, so it won’t install unless an end user mucks around in the macOS security settings. Even then, a victim would have to go on to enter their iCloud password into the app after it's installed before cloud-based data could be extracted.

 

Based on the description of MacStealer from Uptycs, the security firm that spotted the ad, I don’t think people have much to worry about. And even if the malware does pose a threat, that threat extends not just to passkeys but to anything else that hundreds of millions of people already store in iCloud Keychain.

 

Q: Passkeys give control of your credentials to Apple/Google/Microsoft, to a third-party syncing service, or to the site you’re logging in to. Why would I ever do that?

 

A: Assuming you’re using a password to sign in to a service such as Gmail, Azure, or Github, you’re already trusting these companies to implement their authentication systems in a way that doesn’t expose the shared secrets that allow you to log in. Logging in to one of these sites with a passkey instead of a password gives the sites the same control—no more and no less—over your credentials than they had before.

The reason is that the private key portion of a passkey never leaves a user’s encrypted devices. The authentication occurs on the user device. The user device then sends the site being logged into a cryptographic proof that the private key resides on the device logging in. The cryptography involved in this process ensures that the proof can’t be spoofed.

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 into 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 into 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 t 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.

 

Source