Passkeys & WebAuthn

Passwords have three chronic weaknesses, and all three trace back to the same root cause: a password is a shared secret, and both the user and the server have to know it. Reuse happens because nobody can remember a unique password per site, so one breach unlocks many accounts. Phishing works because a password carries no built-in notion of which site it belongs to — a convincing fake login page can extract it just as easily as the real one. And breaches matter because the server has to store something to check a password against; when that database leaks, the stored hashes (covered in the key-derivation-functions module) become an offline cracking target.

A passkey replaces the shared secret with a key pair. The private key is generated on, and never leaves, the user's device (a phone, laptop, or hardware key); the server only ever receives and stores the matching public key. The server literally has nothing left worth stealing — a leaked passkey database reveals only public keys, which are already public by design.

Signing up for a passkey is a textbook public-key generation step, run inside secure hardware rather than in software. The site's server sends a random challenge and its own identity (the relying party ID — essentially its domain). The user's authenticator — a Secure Enclave, a TPM, or a dedicated hardware key — generates a fresh key pair specifically for that site, signs the challenge with the new private key to prove the hardware genuinely produced it, and returns the public key plus that signature. The server verifies the signature and stores the public key, tied to that user's account.

Authentication is a direct application of the challenge-response identification pattern that underlies the Schnorr signature scheme covered in the ElGamal module: the server sends a fresh random challenge, the device signs it with the stored private key (after the user unlocks that key locally with a biometric or PIN), and the server verifies the signature using the public key it already has on file. Nothing secret ever crosses the network in either direction — not in registration, and not here.

A fresh challenge every time is what turns this into proof of live possession rather than a replayable secret: signing yesterday's challenge proves nothing about today's login attempt, unlike a password, which is exactly as useful to an attacker on its hundredth use as its first.

Passwords and even one-time codes both fail against phishing because a human has to judge whether a login page is legitimate — and attackers are very good at making that judgment fail. WebAuthn removes the human from that specific decision: the browser itself binds every key pair to the exact origin (scheme + domain + port) it was created on, and will only ever offer a key to the origin that owns it. A phishing site at a lookalike domain isn't shown a slightly-suspicious login form the user might click through anyway — it's never even offered the credential to begin with, because the browser's own origin check fails before any signing happens.

This is the single biggest practical difference between passkeys and SMS or app-based one-time codes: an OTP is just another shared secret the user can be tricked into typing into the wrong site, while a passkey's origin binding makes that specific trick structurally impossible, not just less likely.

Not every passkey has an identical trust model. A device-bound passkey never leaves the secure hardware it was created on — maximally resistant to extraction, but unusable if that device is lost, with no backup. A synced passkey backs up an encrypted copy to the user's cloud keychain (iCloud Keychain, Google Password Manager), so it's available on a new device automatically — at the cost of trusting that cloud provider's own encryption and account-recovery process as part of the overall security model.