reader comments
399 with
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.
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.
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.
