Heads up: posts on this site are drafted by Claude and fact-checked by Codex. Both can still get things wrong — read with care and verify anything load-bearing before relying on it.
why → how

Passkeys: why the password is finally being replaced

Passwords are a shared secret you keep retyping into whatever site asked. Passkeys move the secret onto your device and never let it leave.

Security intro Apr 29, 2026

Why it exists

Every password-based login has the same shape: you type a secret, the site checks it against a stored hash, and if they match you’re in. That model has two failure modes that no amount of UX polish ever fixed.

The first is the breach. The site stores something derived from your password. If they hash it well, attackers crack a fraction. If they hash it badly — or in plaintext, which still happens — attackers crack all of it. Any password you reuse is now a key to other accounts.

The second, worse failure is phishing. You don’t even need a breach. You just need a fake login page that looks convincing. The user types the real password into the wrong site and hands it over. Two-factor codes via SMS or TOTP help, but they’re also typeable, so a phishing site that proxies through to the real site in real time can catch the code too. This is how most modern account takeovers actually happen — not brute force, social engineering plus a look-alike domain.

Passkeys exist because the underlying problem is the shared secret itself. As long as authentication is “type a thing the server already knows,” the thing can be stolen, leaked, or fooled out of you. The fix is to stop sharing the secret at all.

Why it matters now

Apple, Google, and Microsoft shipped consumer passkey support across their platforms through 2022–2023, and large sites — banks, GitHub, Amazon, Shopify — added them through 2023–2024. As a software engineer in the AI era you’ll hit this from two sides: as a user being prompted to “create a passkey” on sites you log into, and as someone who’ll eventually have to integrate WebAuthn into a product. Both angles get easier once you see the shape.

Phishing resistance is the part LLMs make more urgent, not less. AI-generated phishing kits, voice-cloned support calls, and convincing fake login flows are cheaper than ever. A credential that literally cannot be phished — not because users are careful but because the protocol won’t let them hand it over — is a structural defense, not a behavioral one.

The short answer

passkey = device-held private key + origin-bound challenge-response over WebAuthn

A passkey is a public/private keypair that lives on your device (phone, laptop, hardware key). The site stores only the public key. To log in, the site sends a random challenge; your device signs it with the private key; the site verifies with the public key. The private key never leaves the device, and the browser ties the signature to the exact origin you’re on, so a fake site gets the wrong signature.

How it works

Three pieces, all already in your browser.

1. Registration. When you “create a passkey” on a site, the browser generates a fresh keypair scoped to that site’s origin (https://example.com). The private key is stored in the platform’s secure store — TPM on Windows, Secure Enclave on Apple devices, equivalent on Android. The public key is sent to the site and stored against your account, along with a credential ID the site echoes back later to say “use this passkey.”

2. Login. The site sends a random challenge. The browser asks the platform to sign it, gated by a local user verification step. The platform signs (challenge + origin + credential ID) and returns the signature. The site verifies it against the stored public key.

3. Why it can’t be phished. The signature includes the origin the browser saw in the URL bar. If the user is on examp1e.com (look-alike domain), the browser signs with that origin — which doesn’t match the public key example.com has on file, so verification fails. The user’s device refuses to help the attacker, not because the user noticed, but because the protocol binds the credential to the real origin. There’s no string the user could have typed that would have leaked it.

This is the standard called WebAuthn (the browser API) running on top of CTAP2 (how the browser talks to the authenticator), both shepherded by the FIDO Alliance. “Passkey” is the consumer-friendly name for a WebAuthn credential that’s also synced across your devices via your platform account (iCloud Keychain, Google Password Manager, etc.) — so losing your phone doesn’t lock you out forever.

That sync is the seam worth showing. The original FIDO2 design assumed each credential was bound to one device — security through non-portability. Real users hated that: lose the device, lose the account. The platform vendors added end-to-end encrypted sync so passkeys roam with your platform identity. Critics point out that this re-introduces a form of recovery risk: if your Apple ID or Google account is compromised, your passkeys travel with it. The honest read is that passkeys move the trust anchor from “every individual site’s password” to “your platform account,” which is a much smaller, much better-defended surface — but it is a surface, and the mental model of “unphishable” applies to the protocol, not to your iCloud recovery flow.

I don’t have a clean public number for what fraction of breaches passkeys would have prevented; the verifiable claim is the narrower one — the challenge-response is origin-bound, so credential phishing as a class doesn’t work against it.

Going deeper