Passkeys: A shattered dream

I'd see having the user add the domain themselves, or get the user to copy/past the password themselves on some other form. But the phishing is not happening on the password manager side, and these use cases still exist even after you chose passkeys (i.e. I'd still need to somewhat log into Google's auth from my Nest hub for instance to have it show the calendar)

With both of these I have little sense of what is going to happen if I lose my phone or switch to a new one. So typical passkey problems.

We were so very nearly there with U2F... I did extensive testing and you can have a U2F (Fido2/webauthn) device deriving it's private keys, never leaving the device's HSM, from a BIP-44/BIP-39 seed. You write 12, 18 or 24 words down (out of a dictionary of 2048 words) and with these words, you can always reinitialize another Ledger Nano (a cryptocurrency hardware wallet but I didn't care: I was after the U2F "nano app").

It just worked. It was beautiful. My seed were written on paper sheets which I'd store in a safe at the bank / at my parents' home, etc.

As a bonus the hardware device would display, on its little screen, if you were enrolling or login (a useful info) and, for known provides, it'd display the name. For example "login to google?" / "enroll to dropbox?".

Pure beauty.

Then sadly this trainwreck that passkeys are happened, greatly lowering not only the security of 2FA (someone is in control of all your keys and they can be "backed up": what a concept!) but also making you lose the ability to backup your own keys/seed.

I do really hope at some point we see a future "passkeys nano app" for hardware devices on which the user is in control of the master seed used to derive the keys. It worked for FIDO2/webauthn. I hope it'll work again at some point in the future for passkeys.

OK, so the simplest way to understand is to first know about the previous generation.

U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes.

In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compromised machine. You get a separate public/private key pair for every account and website (so it can't be used to track you between websites) and that key pair can be used to authenticate with the website. A physical button has to be pressed to authenticate, keeping it secure even if an attacker has control over your keyboard and mouse. The browser integration takes care of letting the USB key know which website is asking to authenticate. U2F keys have to be used alongside a username and password.

For a variety of reasons U2F keys never really took off. Partly cost, partly the 'what if I lose it' issue, partly lack of uptake by websites, partly difficulty using them on mobile, partly competition from 'log in with google' type systems.

So the trade group behind U2F said "Hey, maybe we could just emulate the hardware secure element in the smartphone's OS? And while we're at it, we could save the username, and use fingerprint/faceid instead of a password, eliminate that tedious button press, and automatically back up the public/private keypairs to the cloud". They kept a USB option about for the sake of tradition, but it's on life support.

So that's the mental model of a Passkey: It's like an impossible-to-clone USB hardware secure element that does challenge-response authentication to websites. Except it's emulated in OS software, and is no longer impossible to clone.

Another way of thinking of it is: It's very similar to using the 'Log in with Google' / 'Log in with Apple ID' buttons you see on many websites, you're authenticating to a service by proving you have access to a cloud account. The implementation details in the background are very different, but the result is broadly the same.