7.4 Phishing-Resistant Architecture and Passkeys
The Ceremony, Step by Step
WebAuthn (the W3C standard behind FIDO2 passkeys) replaces the shared secret with a keypair. During registration, the browser calls navigator.credentials.create(); the authenticator — a platform secure enclave or a roaming FIDO2 security key speaking CTAP2 over USB, NFC, or BLE — generates a keypair, keeps the private key permanently inside tamper-resistant hardware, and returns the public key plus a credential ID to the relying party (RP), tagged with the RP’s origin (its rpId domain). During authentication, the RP sends a fresh random challenge; the browser forwards it to the authenticator, the user verifies locally with biometrics or a PIN, and the authenticator returns a signature over a client-data hash that covers the challenge, the ceremony type, and the exact origin.
Why the Fake Site Gets Nothing
Three properties combine into phishing resistance. First, origin binding: the authenticator refuses to sign anything unless the requesting site’s origin matches the registered rpId, so a look-alike domain cannot even ask the key to participate, and any forged signature fails RP verification anyway because the origin is baked into the signed hash. Second, freshness: the signature covers a one-time challenge, so relaying it to the real site is a replay of a spent, mismatched value. Third, no secret to steal: the public key is public; nothing transmitted is reusable, so a fully proxied phishing site sits between two honest parties and harvests zero usable material.
Syncable Passkeys vs Hardware Tokens
Platform passkeys live in a device’s secure enclave and sync through ecosystem keyspaces (iCloud Keychain, Google Password Manager) wrapped by the account’s keys, giving one credential across phone and laptop. Roaming security keys are separate hardware per credential — the most phishing-resistant option available — and work across ecosystems. Both require user verification on the device per ceremony, so a stolen, unlocked laptop still cannot sign. Practical residual risks are the human lanes: account-recovery pages that fall back to SMS, and help-desk re-enrollment. Enroll two keys per account, delete SMS fallback, and monitor enrollment changes as high-severity events.
Architecture Diagram
Key Takeaways
- WebAuthn swaps a reusable shared secret for a per-account keypair whose private half never leaves the authenticator.
- Signatures cover a fresh challenge plus the exact origin, so harvested or relayed responses are worthless.
- The authenticator checks the requesting domain against the registered rpId before signing — phishing resistance is enforced client-side, in hardware.
- Platform passkeys sync across devices; roaming FIDO2 keys give per-device isolation and the strongest guarantee.
- Secure the human lanes: remove SMS recovery fallback and alert on credential re-enrollment.