Passkeys and WebAuthn

What a passkey actually is

A passkey is a WebAuthn credential: an asymmetric key pair where the private key never leaves the authenticator (a phone’s secure enclave, a laptop’s TPM, or a roaming hardware key like a YubiKey) and the server stores only the matching public key. There is no shared secret. The server has nothing an attacker can phish, no password database to leak, no seed an attacker can mirror. That alone is a category change from passwords and TOTP, where the server holds a verifiable secret and so does anyone who steals it.

Two ceremonies define the protocol. Registration (navigator.credentials.create) generates a fresh key pair scoped to your site’s rpId (the registrable domain, e.g. example.com) and ships the public key to your server, which stores it against the user. Authentication (navigator.credentials.get) proves possession of the private key: the server sends a one-time random challenge, the authenticator signs over it (plus context), and the server verifies the signature against the stored public key. Possession of the key, gated by a local user-verification gesture (biometric or PIN), is the proof of identity.

The crucial part is what gets signed. The authenticator does not sign the bare challenge. It signs a structure that includes the clientDataJSON — and the browser, not the page’s JavaScript, fills that object with the page’s real origin and the server’s challenge. The signature therefore binds the assertion to the exact origin the user’s browser was actually on. That binding is the whole game.

Why the relay attack fails: the origin is signed, by the browser

Walk the adversary-in-the-middle (AiTM) attack that defeats passwords and TOTP, and watch it die against a passkey. The attacker runs a reverse proxy on a look-alike domain that faithfully forwards your real pages. The victim lands there and authenticates. With a password, the proxy reads the typed secret and replays it to the real site — game over. With TOTP, the proxy reads the typed 6-digit code and replays it inside its validity window — game over. These work because the secret is a readable bearer value: whoever captures it can present it anywhere.

A passkey breaks the pattern at the byte level. When the victim’s browser builds clientDataJSON, it writes the page’s origin into it — and the page is accounts-secure-login.com. The authenticator signs over those bytes. The proxy relays the resulting assertion to your real server, which expects origin accounts.example.com. On verification the signature is cryptographically valid but bound to the wrong origin, so the server’s origin check rejects it. The proxy cannot fix this: it cannot make the browser lie about the origin (the browser fills the field, not the page’s JS), and it cannot re-sign for the correct origin because it never had the private key. In practice the authenticator usually won’t even surface the credential, because the look-alike domain’s rpId won’t match what the passkey was registered to — so the ceremony fails before a signature exists. The attacker is left holding a valid signature that is worthless everywhere except the phishing domain it was bound to.

The tradeoffs you actually accept

Adopting passkeys is not free, and the costs are not where beginners look.

Recovery becomes the hardest part, not the login. A passkey lives on a device or in a sync fabric. Users lose phones, wipe laptops, and switch ecosystems. So you must offer recovery — and recovery is where the security of the whole account is silently decided. If your recovery path is “email me a reset link,” and that email account is protected only by a password, then the true strength of the account equals a phishable password on a third-party mailbox. You built an unphishable front door and left a phishable side door wide open. The rule is blunt: recovery must be at least as strong as the primary factor. The cleanest answer is to register two passkeys at enrollment (one platform, one roaming hardware key), so the second credential is the recovery method — no weaker channel needed.

Synced vs device-bound passkeys is a real trust decision. Modern consumer passkeys sync across a user’s devices through their platform account (iCloud Keychain, Google Password Manager). That is wonderful for adoption — lose a phone, your passkeys are on the new one — but it means the credential’s security now also depends on the platform account’s security, and it means the old assumption that “the private key lives in one tamper-resistant chip” is no longer true. Device-bound passkeys (a hardware security key, or platform keys with a no-sync policy) stay in one place and are stronger against account-level compromise, but they make loss catastrophic unless you’ve registered a backup. For high-assurance contexts (admin, finance, regulated systems) you often require device-bound keys and attestation; for consumer scale you accept synced keys and lean on platform-account security. Knowing which you have is part of your threat model.

signCount is not the tamper-evidence it once was. WebAuthn’s authenticatorData carries a signature counter meant to detect a cloned hardware authenticator: if the counter ever goes backwards, you’ve seen a clone. That signal is real for single-device hardware keys. But synced passkeys are copied across devices by design, so their counter is frequently 0 or meaningless across the fleet — a regression isn’t proof of compromise. Treat signCount as a soft signal, never a hard gate, and never as the thing standing between you and a cloned credential on a synced platform.

Where it breaks: WebAuthn only secures the login event

The most expensive passkey mistake is believing the credential secures the account. It secures exactly one thing: the authentication event. Everything around it is still your responsibility, and that is where teams who “went passwordless” still get taken over.

The session is still a bearer token. A passkey login mints a session cookie — and that cookie is cash, exactly like before. If you never rotate it, give it a long lifetime, and let third-party script run on the authenticated page, a single XSS exfiltrates a live session and the attacker is in without ever touching the passkey. WebAuthn made the login unphishable; it said nothing about what happens after. You still need session rotation on login and privilege change, short lifetimes with re-auth, HttpOnly/Secure/SameSite cookies, and a CSP that stops injected script from reading the session.

Possession on an unlocked device defeats user verification. WebAuthn proves possession of the key, gated by a local UV gesture — but on an already-unlocked laptop the OS may have the gesture cached or auto-satisfy it. A thief with a stolen, unlocked device can use a synced passkey to sign in, and the cryptography is working exactly as designed. There is no crypto flaw to find. The defense is layered controls above the login: explicit step-up re-authentication (userVerification: 'required') for sensitive actions, risk signals (new device, new geo, impossible travel), short bound sessions, and — critically — keeping authentication separate from authorization, so a privileged action re-checks both “is this the right human right now” and “is this principal allowed,” instead of trusting a passive session minted hours ago.

How a senior actually deploys passkeys

Treat the passkey as a strong authenticator, not a complete identity system, and harden the chain around it. Register two credentials at enrollment so recovery is a second passkey, not a phishable reset link. Migrate the password away once coverage is real, rather than keeping a permanent weak parallel path. Make recovery at least as strong as the login — second passkey or hardware key first, and where an out-of-band reset must exist, add friction (delay, notification to all devices, step-up, an enrollment-time recovery code). Add step-up for sensitive actions so a passive session can’t act, and rotate and bound sessions so a stolen one expires fast. Decide synced vs device-bound deliberately per assurance level. And write down the standing assumption — a passkey secures the login, not the session, the recovery, or the device — so nobody re-makes the “login is enough” mistake. The test for any passkey deployment is one walk: trace every path that can land an attacker in the account, and confirm none of them is more phishable than the passkey itself.