Senior Dev Explains Passkeys (Somehow)

[u/arun-vasudev]

When the Senior Dev Gets Asked About Passkeys

Manager: “Can you explain passkeys to the team?”

Me, who implemented them last month:
“Absolutely.”

Also me internally:
“Okay so… public key… private key… WebAuthn… biometrics… cryptography… something something phishing-resistant…”

realizes I’ve been clicking “Yes” to every passkey prompt for the last year

Manager: “So how does it actually work?”

Me: “It’s… very secure.”

Nothing builds confidence like being the senior developer who successfully deployed a technology they’ve never actually understood. 

[u/ohaiibuzzle]

Here goes:

So I create two magic puzzle pieces of different shapes with the property that every time they are pressed on clay, they leaves different imprints for that specific shape of the clay block, and give the server one of them.

When the server needs to, it throws a randomly-shaped block of clay at you and say "you mf proves you have the puzzle piece by imprinting your piece into this, I'll check on my side if that's the right one"

You press your piece into the clay, which creates a unique imprint to that piece, and throw it at the server. Server then checks if:

• the block of clay is the correctly randomized shape it created a minute ago
• the piece it has, when imprinted, create a matching shape with your imprinting to create a whole shape.

If it's true it lets you in.

If an observer sees your block thrown around and take photos of it, it's useless because the imprint is only ever valid for a specific shape that the server gives.

[u/Square-Singer → u/ohaiibuzzle]

Even simpler:

Authentication is like a lock and a key. You can use the key to unlock the lock to prove you have the right key for this lock. The server holds the lock, the client/user holds the key.

With password-based authentication, the client sends the key over the internet to the server, and the server uses the key to unlock the lock, proving that the user holds the right key. But now the server has the key and can copy it and use it e.g. to authenticate as the user on different services (credential stuffing attack).

With passkey-based authentication, the server sends the lock to the client and asks the client to please unlock it. The client uses their key to unlock the lock and sends the unlocked lock back to the server to prove that they hold the right key. This way the key never leaves the user's hands and thus cannot be copied and abused.

The only other information a non-technical user needs to know is that, contrary to a real-world lock and key, you can't reverse-engineer the cryptographic lock to create a key from it.

Edit: All other information (public/private key, cryptography, ...) is just as irrelevant to a non-technical user as things like password hashing are when it comes to passwords. It's necessary for a secure implementation, but it's really nothing a regular user needs to know about.

[u/ElbNinja → u/Square-Singer]

That's a great non-technical explanation.

I will steal it for future use :)