Okay, okay, okay. We are finally going to describe how passkeys work. Sorry for drawing it out this long, but it’s important to lay the groundwork first. If you don’t understand the flaws of passwords or how public-key cryptography and digital signatures work, it can be hard to see what passkeys are bringing to the table. You may think it’s all just the latest scam that Google and Apple cooked up to try and suck your blood/data.
For those of you who are just joining us on this jaunt through the realm of passkeys, here are links to the first three newsletters to get you up to speed:
Securely authenticating users with passkeys involves two major processes. The first is registration, which is basically setting it up, while the second is authentication, which is when users log in with their passkeys.
First, you need a WebAuthn Authenticator, which the latest versions of Android, iOS, MacOS and Windows generally take care of for you. WebAuthn Authenticators are either software or hardware-based cryptographic entities which allow users to register with a relying party, store keys, and authenticate themselves. Relying parties are apps or websites that use WebAuthn Authenticators to register and authenticate users. Basically, they are websites that have adopted passkeys to give users a simpler sign in option, such as Google, Adobe or PayPal.
Registration
Let’s say that you are using your phone to log in to example.com via your normal username and password. The site has recently implemented passkeys, making it a relying party. This time when you log in, you get served a script from example.com prompting you to set up passkeys. You accept, which prompts the client to look for the WebAuthn Authenticator on your device.
The client connects to the WebAuthn Authenticator, and the WebAuthn Authenticator then pops up asking you to enter your phone’s PIN, pattern, or biometrics. This prompts the WebAuthn authenticator to create a private and public key pair. The private key stays protected by the WebAuthn Authenticator, on your device, while the public key is sent to example.com and stored in a database on one of its servers.
Once you are registered, you can use your passkeys to log in to your account instead of your username and password—however these login credentials will still work.
Authentication
The next time you go to example.com to log in, you will be served a script asking for authentication via passkeys. If you accept, the server sends a cryptographic challenge. The client then searches the device for the WebAuthn Authenticator and connects to it. The WebAuthn Authenticator then presents you with a popup, asking you to authenticate with whichever measure you used during registration, whether it was your PIN, pattern or biometrics.
Once you have entered your PIN, pattern or biometrics, the WebAuthn Authenticator completes the cryptographic challenge by signing it with your private key, forming a digital signature. The client then forwards this in a response to example.com’s script, which then transfers the signature to the server so that it can be validated with your public key that example.com’s server has stored in its database.
If the digital signature is validated, your authentication is successful and you will be logged in. It sounds pretty complicated when you look at it all written out, but most of this takes place in the background. From the user’s perspective, you just go to the site, click the account you want to use, enter your PIN, pattern or biometrics, and you are ready to go.
The security implications of passkeys
Now that we have delved a little into the mechanics, you can see what actually takes place when passkeys are implemented. Note that no sensitive information is sent during any of the interactions we discussed.
Your PIN never leaves the device, neither does your pattern, nor your biometrics. The WebAuthn Authenticator uses them to authenticate you locally, then signs a cryptographic challenge with your private key to create the digital signature. There is no password to speak of in this flow, and the digital signature isn’t a sensitive value that we are concerned about hackers uncovering.
This helps to limit a bunch of the issues with passwords:
- The user isn’t in charge of creating the keys, so they can’t create weak keys that can be brute forced. However, they could still have a weak PIN or pattern, like 1-1-1-1, which would leave them vulnerable.
- Users can’t forget their passwords. A user doesn’t have to remember anything if they use biometrics. They only have to remember their PIN or their pattern if that’s what they use to lock their phone. This is all they will need to know to log in to each of their accounts that use passkeys.
- It’s faster and easier.
- Users can’t be tricked in phishing attacks because they don’t know their keys. This is critical, because phishing is such a common attack vector.
