Passkeys: your friendly password replacement

29 Jan 2024 by cthos
About 6 min

Update: 04-26-24 - whooboy, so apparently I've missed some marketing nonsense around Passkeys. At some point, someone decided that Passkey === Resident Key and that apparently stuck? I wasn't aware of that, but I'm gonna link to a technical blog here where you can read more about the chaos.
As a result, this means the information below is a little...weird? Like, it's all still accurate except apparently "passkey" means "usernameless / discoverable key" in public parlance. Which is dumb? I don't like that. Yubikeys can only store up to 25 resident keys which makes them way less useful. Very handy in say, the Apple ecosystem still, but hey. I've added another sidebar in the context.

One of my absolute favorite topics to rant about continually is identity and access management (specifically authentication). One of my friends prompted me to write about this after needing some questions about passkeys answered.

Anyhow, one of the most thrilling innovations in identity managements in recent years that is finally seeing wider adoption is Passkeys. Put simply, Passkeys replace the need for passwords by shunting the authentication checks to a combination of something you have (a phone, or security key) with something you are (biometrics) to authenticate to a website or a service. No longer do you need to use a password manager to log in securely to a site, or remember a secret phrase, so long as you have your device and you remain you - you can access your content.

They’re unphishable, because you can’t just hand them over - you physically need to be in possession of the device. You can’t forget them. There’s nothing to remember. Stealing an entire database of public keys gets you basically nothing, you can’t really use those public keys to impersonate anyone - and because they’re website-specific, they’re immune to credential stuffing. They’re (usually) behind biometrics - so even if your device is stolen, the thief also must worry about faking your face or fingerprint. It makes the cost / time investment in stealing credentials much harder.

The way it does this is all behind-the-scenes and the end user doesn’t need to really understand how any of it works, but today we’re going to dive into that just a bit so you can peer behind the curtain and understand the limitations and risks of bad implementations.

Easy! Public Key Cryptography! … wait that’s not easy? Right, okay, let’s start from the beginning. Passkeys are based on the concept of public key cryptography, in which a system generates a pair of keys on a device - a public key and a private key. The public key can encrypt data so that only the private key can decrypt it, and vice versa. Because the private key never leaves the device, you can hand out the public key so that folks can encrypt data so that only you (the device that holds the private key) can decrypt it. You can also create signatures which simply prove possession of a key without encrypting the data.

Passkeys, using a protocol called WebAuthN, take advantage of this by exchanging public keys back and forth so that when you register / log in, that you have your private key becomes your authentication proof.

The registration flow for a “brand new account” essentially works like this (I’ll be leaving out a fair amount of detail for the sake of understanding - if you want the full picture, the WebAuthN spec, Google, and Apple all have wonderfully detailed guides for implementing Relying Parties).

Okay, so for this section a "resident key" can also be usernameless, meaning the app can just straight sign you in without asking for an identifier - and apparently the wider passkey marketing means that's necessary. Which it's not actually necessary, but here we are.

1. You visit a website and click “register”.
2. For non-resident keys only: The website prompts you for some sort of identifier (most commonly email address, but could be username or anything, really) - or generates one for you.
3. Your device prompts you to create a new passkey, and has you biometrically authenticate (face/touch ID, on iOS).
4. For Resident Keys: Your device generates a new public / private key pair specific to that website’s domain name and sends the public key to the website. For Non-Resident Keys: a seed gets generated and stored against the identifier - that seed is what is used by the hardware token in conjunction with the private key resident on the token to ber unique per-site (still specific to the website's domain).
5. The website stores your public key along with your identifier for future use; you are now registered.

This flow can also work for an existing legacy username/password account to add a new passkey to that old account - the only difference is the website already knows what account to associate the passkey to.

For login, the operation is very similar, but there’s an additional challenge mechanism in place.

1. You visit the website, enter your username/email/whatever to identify which account to log into (the browser can also store this for you, so it knows you already).
2. The website issues a challenge back to your device, basically: “I need you to prove you have this private key by using it to sign back this data I’m sending you”.
3. Your device prompts you to use the stored passkey for this website and has you biometrically authenticate.
4. Your device creates an attestation - which is the response to that challenge, but signed using the private key.
5. The website uses the public key (or seed as necessary) to check that the assertion was signed correctly. If it was, then you are now logged in! If it wasn’t, the site rejects your credentials.

If you’re interested in the technical details, but do not want to read the spec, I recommend this guide on WebAuthN.guide, or the Google implementation Sandbox.

It’s really not all that different - many of the same mechanisms that Apple uses for in-app FaceID also apply to Passkeys, they’re built on very similar tech.

Same deal for Google’s biometric implementations, a lot of the same plumbing powers the overall ecosystem.

You may have noticed that there’s a potential problem if the identity is tied to a single device - how do you log in if you’ve lost the device? There are a couple of ways to handle this on both the device side and the provider / website side.

Apple and Google handle this by synching that private key to your cloud account on either platform - encrypted by the master password on your account. That way, you can use the same passkey on any device you own in the same ecosystem, protected by the same biometrics. For 95% of people, this is sufficient. Even if you lose your phone, so long as you can still get into Google / iCloud your credentials are safe. This means you still need one password - for your cloud account, but you can also protect that via something like a Yubikey stored in a lockbox or something.

On the provider side, they can offer you the ability to enroll multiple passkeys, so that you can keep one as backup on a physical security key. They can also offer robust backup options - currently this is typically 10 or so random “break glass” codes that you can print off and keep in a safe somewhere. They also still have the option of offering traditional SMS recovery, but your security is only as good as the weakest recovery method - and SMS is extremely insecure.

For those extremely paranoid, you can buy hardware authenticators and use those to generate passkeys, but you are responsible for backups at that point - you want to keep one somewhere safe in the event you drop your token in a gorge.

Note: Yubikeys support at most 25 resident "usernameless" keys.

I think so. To put it extremely bluntly, passwords are awful. They can be stolen. You can forget them. We’ve been trying for years to get the less tech-savvy among us to adopt (and pay for!) password managers to create strong random passwords so that perhaps we can prevent credential stuffing. That hasn’t worked, because the barrier to entry is high and confusing.

The barrier to entry for passkeys is basically zero: “Do you want to let FaceID / TouchID manage this login for you?”. For most people, it will “just work”, and for the rest of us, our password managers or hardware tokens are for us to manage.

I don’t know if passwords will ever fully go away, but I sure hope that passkeys take out a huge chunk of them, and soon.

blog IAM authentication passkeys