Google's adoption of passkeys (security blog article)

Yesterday Google announced that you can use passkeys to log into your Google account. The announcement caused a lot of confusion on Hacker News because it didn't explain how anything worked. Here's a Google security blog article that goes into a bit more depth.

Unlike passwords, passkeys can only exist on your devices. They cannot be written down or accidentally given to a bad actor. When you use a passkey to sign in to your Google Account, it proves to Google that you have access to your device and are able to unlock it. Together, this means that passkeys protect you against phishing and any accidental mishandling that passwords are prone to, such as being reused or exposed in a data breach. This is stronger protection than most 2SV (2FA/MFA) methods offer today, which is why we allow you to skip not only the password but also 2SV when you use a passkey. In fact, passkeys are strong enough that they can stand in for security keys for users enrolled in our Advanced Protection Program.

While you can't give your passkey to a bad actor, you might need to give your phone to a bad actor. It requires physical access though, and probably they need to get you to unlock it, so this is limited to muggers, police, or other people who can threaten you. Or people you live with and perhaps overly trust.

I think what they're trying to say here is that a cell phone with a passkey is just as good as a hardware device like a Yubikey. It's a big claim, but maybe it's true along some dimensions?

What if you lose it?

If you lose a device with a passkey for your Google Account and believe someone else can unlock it, you can immediately revoke the passkey in your account settings. If your device supports the option to remotely wipe it, consider doing that as well, especially if it also has passkeys for other services. We always recommend having a recovery phone and email on your account, as it increases your chance of recovering it in case someone gains access.

So sure, in general, the way you protect against lockout is by having multiple independent ways to log in. They say "recovery phone" rather than "recovery phone number" which is a bit odd; is it a mistake, or does it not need a phone number? I suppose you could have an old phone that you didn't wipe for use as recovery, but I'm a bit wary of it since it might not continue to work. I expect a Yubikey to be more durable, and printing out backup codes and storing them in a safe seems even better as it doesn't depend on hardware other than the safe. Also, people often have multiple devices (phone and tablet, for example), which is pretty good, though you could lose both if you have them on you.

One thing I'm a bit wary of is "passkey syncing." What does that mean?

The private key behind the passkey lives on your devices and in some cases, it stays only on the device it was created on. In other cases, your operating system or an app similar to a password manager may sync it to other devices you own. Passkey sync providers like the Google Password Manager and iCloud Keychain use end-to-end encryption to keep your passkeys private.

Okay but how? Here's the blog entry for how it's done in Google Password Manager:

A single passkey identifies a particular user account on some online service. A user has different passkeys for different services. The user's operating systems, or software similar to today's password managers, provide user-friendly management of passkeys. From the user's point of view, using passkeys is very similar to using saved passwords, but with significantly better security.

[...]

To address the common case of device loss or upgrade, a key feature enabled by passkeys is that the same private key can exist on multiple devices. This happens through platform-provided synchronization and backup.

Passkeys in the Google Password Manager are always end-to-end encrypted: When a passkey is backed up, its private key is uploaded only in its encrypted form using an encryption key that is only accessible on the user's own devices. This protects passkeys against Google itself, or e.g. a malicious attacker inside Google. Without access to the private key, such an attacker cannot use the passkey to sign in to its corresponding online account.

And what special magic lets it do end-to-end encryption? How does it decrypt?

In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.

To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. Note, that restoring passkeys on a new device requires both being signed in to the Google Account and an existing device's screen lock.

Emphasis added. I guess it's encrypted multiple ways and if you forget everything about your old device, you're out of luck? Also, if you ever get to the point where you're not logged into Google on any device, and can't log in, you're out of luck. So, this synchronization is limited and having an alternative if you get locked out is a good idea.

One risk that Google never addresses is what happens if Google cancels your account. For people who have Apple equipment, maybe you'd prefer to use Apple's passkey implementation to Google's passkeys. I might end up using both for redundancy.

So where do we end up if passkey use becomes common? It's a world where people have multiple personal devices protected by screen lock (etc), having any one of them gives you access to your accounts, and you never use passwords. Redundancy comes from having more devices.

But it seems like the more devices you have, the more likely you are to lose one without noticing? This might get rid of passwords but it won't get rid of all lockout scenarios or all break-in scenarios. A lot of common cases get solved and some kinds of crime might go away for most people, but hard cases are still hard.

The hardest case I know of is a homeless person with no physical security and who loses everything repeatedly. If someone can solve recovery for them then there's likely nothing more to do. Maybe someday?