An attacker registers chase-secure-login.com, sets up a pixel-perfect copy of Chase's login page, and sends phishing emails that link to it. The victim clicks. What happens next depends entirely on which credential they're about to use.
The two simulations below run the same attack against the same victim. The left side uses a password; the right side uses a passkey. Click "Submit" on each and watch the outcomes.
Why the password got stolen
The lookalike site asked for a username and password. The browser has no way to know the site is fraudulent. The user types real credentials. The attacker's web server receives them. The attacker then logs into the real chase.com using those credentials — from their own machine, in their own country — and the account is theirs.
- The phishing page looks identical to the real one. The user has no visual cue to act on.
- The browser does not verify the destination matches the user's intent. It just sends the form fields to whatever URL the form posts to.
- The password is a bearer credential: anyone who holds it can present it anywhere. It doesn't care which domain it's typed on.
- Even MFA via SMS or TOTP often falls to this attack — the lookalike asks for the one-time code, the attacker relays it to the real site within the validity window.
Why the passkey refused
A passkey is a public-key credential bound to a specific origin at registration. When the user registered their Chase passkey, the browser tied that credential to the exact origin https://chase.com. The credential cannot be presented to any other origin. Not chase-secure-login.com. Not chase.com.attacker.io. Not even http://chase.com (different scheme).
When the lookalike site invoked WebAuthn to ask for an assertion, the browser checked the calling origin against the credentials stored for that origin. There was no credential registered for chase-secure-login.com, so the browser returned an error. The user's authenticator (phone, YubiKey, Touch ID) was never even consulted. The attack failed at the browser layer — before the user had a chance to make a mistake.
What actually happens at the protocol layer
When a site calls navigator.credentials.get({publicKey: ...}), the browser packages a client data JSON object that includes the origin it was called from. The authenticator signs that JSON. The server then verifies two things: that the signature is valid, AND that the origin in the signed data matches the server's expected origin.
If the attacker captures this signed assertion and replays it to the real chase.com, the real Chase server reads the signed origin field and sees chase-secure-login.com. Mismatch. The login is rejected. The cryptography itself encodes the destination, so a credential stolen from a wrong-origin site cannot be replayed to the right-origin site.
The four protections, stacked
Passkeys defeat phishing because the design stacks four protections:
- Origin binding at registration. Each credential is created against a specific Relying Party ID; it cannot be used for any other RP.
- Origin verification at use. The browser refuses to invoke a credential for an origin it wasn't registered with.
- Signed origin in the assertion. Even if a credential were presented, the signature covers the origin, so a man-in-the-middle replay fails.
- Hardware-bound key material. The private key never leaves the authenticator. There is no shared secret on the server to steal.
A password defeats none of these. It has no origin awareness, no signature, no hardware binding, no asymmetry. The same string you typed on the phishing site is the string that grants access to the real site. That equivalence is what every password phishing attack exploits.
What this lab does not show
Passkeys defeat credential phishing. They do not defeat every attack:
- Endpoint compromise. If the attacker has malware on the victim's machine, they can hijack the session after the user authenticates legitimately.
- Account-recovery flows. Many sites still allow recovery via SMS or email, which can themselves be phished. Passkey-only is rare; passkey-plus-fallback is the norm.
- Social engineering against support staff. An attacker who calls the help desk and convinces them to issue a new passkey on a new device bypasses everything above.
- Synced passkeys across compromised cloud accounts. If your iCloud or Google account is compromised, an attacker can sync your passkeys to their device.
Passwords fail to phishing because the credential doesn't know where it's supposed to go. Passkeys succeed against phishing because the cryptographic primitive itself encodes the destination. There is no way to fool a passkey into signing for the wrong site.
This is the single most important shift in consumer authentication in twenty years. It is also the reason every major bank, every cloud provider, and every operating system is pushing passkey adoption: the attack surface that drives the largest category of account takeovers structurally vanishes.
References
Formatted in APA 7. Alphabetized by first author's last name.
- FIDO Alliance. (n.d.). Passkeys: A new era of secure sign-ins. https://fidoalliance.org/passkeys/
- Grassi, P. A., Fenton, J. L., Newton, E. M., Perlner, R. A., Regenscheid, A. R., Burr, W. E., Richer, J. P., Lefkovitz, N. B., Danker, J. M., Choong, Y.-Y., Greene, K. K., & Theofanos, M. F. (2017). Digital identity guidelines: Authentication and lifecycle management (NIST Special Publication No. 800-63B, Rev. 3). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-63b
- World Wide Web Consortium. (2021). Web Authentication: An API for accessing public key credentials, level 2. https://www.w3.org/TR/webauthn-2/