Lesson 9 of 12 · 7 min read
Passkeys, WebAuthn and Phishing Resistance
In this lesson
TL;DR: A passkey is a WebAuthn credential: a key pair created by an authenticator (a phone, laptop or security key) for one website. The site stores only the public key. To log in, the site sends a fresh challenge; the authenticator signs it together with data the browser fills in, including the page's origin, and the credential is bound to a relying party ID (the site's domain). A phishing site on another domain cannot get a signature it can replay at the real site, so passkeys are phishing-resistant in a way one-time codes and push approvals are not. Synced passkeys copy through a cloud account and meet NIST AAL2; device-bound keys that never leave the hardware are needed for AAL3. Passkeys protect the login itself. Account recovery, fallback methods and stolen session cookies after login are separate problems that attackers will move to.
Before you read
Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.
1A phishing kit proxies the real bank login page in real time. It captures the password and the six-digit code the user types and logs in within seconds. Why would the same kit fail against a passkey?
How a passkey login works
Registration. The site asks the browser to create a credential. The authenticator generates a new key pair for that site, keeps the private key, and returns the public key with a credential ID. The site stores both against the account. No shared secret is created; a breach of the site's database exposes only public keys.
Authentication. The site sends a random challenge. The browser builds clientDataJSON, which records the challenge and the origin of the page that made the request, and asks the authenticator for an assertion. After checking the user (a touch, a PIN or a biometric, all local), the authenticator signs the authenticator data and a hash of the client data with the private key. The site verifies the signature with the stored public key, checks the challenge is the one it issued, checks the origin and RP ID hash are its own, and checks the flags its policy requires.
Authenticator
Phone, laptop or key
Browser
Knows the real origin
Website
Relying party
- Challenge
Website to Browser
1Random challenge, RP ID
The site asks
A fresh challenge prevents replay of an old assertion.
Why it resists phishing
Two bindings do the work. The RP ID rule: a credential is created for a relying party ID, which must equal the page's effective domain or a registrable suffix of it, so login.example.com may use example.com, but no site can claim com or someone else's domain. And the origin in the signature: the browser writes the real origin into the signed client data, so even a relayed assertion reveals where it was produced.
A phishing page at a look-alike domain is stuck. The browser will only ask for credentials for the look-alike's own domain, where the user has none. There is nothing for the user to type, so there is nothing to relay.
Worked example: a real-time phishing proxy
A user receives a convincing message and opens bank-example.co, a proxy that relays the real bank's pages.
| Login method | What the proxy obtains | Outcome |
|---|---|---|
| Password only | The password | Account taken over |
| Password plus a six-digit authenticator code | The password and a code valid for about 30 seconds, relayed at once | Account taken over |
| Password plus push approval | The user approves a prompt triggered by the proxy's login | Account taken over |
| Passkey | Nothing: the browser asks for a credential for bank-example.co, and none exists | Login fails; attacker must try another route |
This is why NIST's SP 800-63B-4 (2025) does not count one-time codes, out-of-band codes or push approvals as phishing-resistant, and defines phishing resistance through binding the authentication to the verifier's name or to the channel.
Password and one-time code
User opens bank-example.co
Types password and 6-digit code
user cannot see the domain trick
Proxy relays both within 30 seconds
Outcome, unsafe: Session stolen
Anything a person can type, a proxy can relay.
Passkey
User opens bank-example.co
Browser asks for that domain's credential
RP ID bound to bank.example
No credential, no assertion
Outcome, safe: Nothing to relay
The decision about the domain is made by the browser, not the user.
Typed secrets travel
Codes and passwords are only as safe as the user's judgement of the address bar.
What the site receives, byte by byte
The authenticator data is at least 37 bytes, and a verifier should understand every field.
| Field | Size | Meaning |
|---|---|---|
rpIdHash | 32 bytes | SHA-256 of the RP ID; must match the site's own |
| Flags | 1 byte | UP (bit 0): a user was present; UV (bit 2): the user was verified with PIN or biometric; BE (bit 3): the credential can be backed up (synced); BS (bit 4): it is currently backed up; AT (bit 6) and ED (bit 7): attested credential data and extensions follow |
signCount | 4 bytes | A counter that should increase with each use; zero if the authenticator does not support it |
Presence versus verification. A touch proves someone is there; it does not prove who. Only user verification, a local PIN or biometric, makes a passkey equivalent to two factors: something you have and something you know or are. Sites that rely on a passkey alone should require the UV flag.
Synced versus device-bound. Synced passkeys are copied between a user's devices through a cloud account, which makes them easy to use and recover, and they report BE and BS. Device-bound passkeys, typically on security keys, never leave the hardware. NIST allows syncable authenticators at AAL1 and AAL2 but states that they shall not be used at AAL3, which requires a non-exportable key.
Attestation. At registration, a site can ask for attestation describing the authenticator's make and model through an AAGUID. With none, the default for consumer sites, the browser strips identifying information; indirect allows privacy-preserving substitutes; direct and enterprise pass the statement through. Enterprises that allow only company-issued keys use attestation with an allowlist of AAGUIDs, checked against the FIDO metadata service, trading privacy and flexibility for assurance.
The standards are current: WebAuthn Level 3 became a W3C Recommendation in August 2026, and the FIDO CTAP 2.2 specification (July 2025) defines the hybrid transport that lets a phone act as the authenticator for a nearby computer.
What passkeys do not fix
Passkeys protect the moment of login. Attackers move to whatever remains.
- 1
1 · Login ceremony
Passkey with user verification
- Bound to the domain
- Nothing to relay
Protected
- 2
2 · Fallback methods
SMS, codes, password still enabled
- Phishable alternatives
- Remove them for privileged users
The obvious next target
- 3
3 · Account recovery
Lost all devices
- Second passkey registered
- Delay and notification
Often the weakest path
- 4
4 · Session after login
Cookies and tokens
- Infostealers copy cookies
- Bind sessions, re-verify for risky actions
Still bearer credentials
- 5
5 · The device itself
Malware on an unlocked device
- Can act as the user
- Device health signals
Outside WebAuthn's scope
The protected step
Passkeys close phishing of the login itself.
- Fallbacks. If a password and SMS code still work, a phishing kit will simply ask for those. For privileged users, remove phishable fallbacks entirely.
- Recovery. Losing every device is where many takeovers happen. Encourage a second registered passkey, and make recovery deliberate: identity checks, a waiting period and notification to existing devices.
- Session theft. After a passkey login, the session is usually a cookie or token, and infostealer malware copies those. Combine passkeys with session binding where available, short timeouts matched to the assurance level (NIST's AAL3 limits are 12 hours overall and 15 minutes idle), and re-verification for sensitive actions. See sessions, cookies and tokens.
NIST's 2025 guidance also changed password rules for whatever passwords remain: at least 15 characters when a password is the only factor and at least 8 within multi-factor authentication, no composition rules, and no forced periodic changes without evidence of compromise. At AAL2, verifiers must offer at least one phishing-resistant option.
Worked example: a bank's policy
A bank offers synced passkeys to retail customers, which meets AAL2. Administrators of the payment console must use device-bound security keys with user verification, meeting AAL3, with sessions capped at 12 hours and 15 minutes of inactivity. The server reads the flags: a synced credential (BS set) is accepted for login, but adding a new payee above a threshold, say 10,000 in the account currency, requires either a device-bound credential or a fresh step-up with user verification. Customers who lose all their devices go through a recovery flow with a waiting period and notifications, and the old credentials are revoked when it completes.
Misconceptions interviewers listen for
- "Passkeys send your fingerprint to the server." Biometrics unlock the key locally; only a signature leaves the device.
- "Synced passkeys meet AAL3." NIST excludes syncable authenticators from AAL3.
- "Consumer sites need attestation." Most use
none; attestation matters where only approved hardware is allowed. - "Phishing-resistant login stops session hijacking." Stolen cookies and tokens after login are still bearer credentials.
- "Recovery is a detail." It becomes the weakest route into the account.
What if · interview follow-ups
Hold your answer as the constraints change
You are rolling out passkeys for a consumer app and for the company's own administrators. The interviewer probes what passkeys protect and what they leave open.
Start here
Why can a real-time phishing proxy not use a passkey, when it can relay a one-time code?
Who decides which domain is asking?
The browser binds the request to the page's own domain and writes the real origin into the signed data. On the phishing domain there is no matching credential, and any signature would name the wrong origin, which the real site rejects. A one-time code is a typed secret, and anything typed can be relayed within its validity window.
Carry it forwardPhishing resistance comes from the browser binding the credential to the domain.
Weak answerSaying passkeys work because they are stronger passwords.
Constraint changes
A user loses every device that held their passkeys. What do you do?
Recovery is an attack surface.
Treat recovery as a high-risk login: verify identity through methods appropriate to the account's value, add a waiting period with notifications to the user's contact points, and register new passkeys while revoking the old ones. Encourage a second passkey in advance. Falling back to SMS without risk checks hands attackers the easiest route.
Carry it forwardDesign recovery as carefully as login, or it becomes the way in.
Weak answerOffering an instant SMS reset.
Constraint changes
An attacker runs an adversary-in-the-middle proxy against your admins. What do they try once passkeys block them?
What else is still enabled?
They target fallbacks: the proxy offers 'use another method' and asks for a password and code. For privileged users, remove phishable fallbacks entirely, require user-verified, device-bound passkeys, and alert on any attempt to use a disabled method.
Carry it forwardRemove phishable fallbacks, or attackers will choose them.
Weak answerKeeping SMS as a backup for convenience.
Constraint changes
The signature counter on a security key goes backwards. What does it mean?
Cloning, and synced credentials.
For a device-bound key it can indicate a cloned authenticator, so flag the credential and require re-verification. Many synced passkeys report a counter of zero, so treat the counter as a signal for device-bound credentials only, not as proof of anything on its own.
Carry it forwardThe counter is a cloning signal for device-bound keys, not a universal check.
Weak answerLocking out every account whose counter does not increase.
Constraint changes
Malware steals an admin's session cookie after a passkey login. Did passkeys fail?
What do passkeys protect?
No; they protected the login, and the cookie is a bearer credential issued afterwards. Bind sessions to the device where the platform supports it, apply short idle and absolute timeouts matched to AAL3, require fresh user verification for sensitive actions, and watch for sessions used from new devices or locations.
Carry it forwardPasskeys secure the ceremony; sessions need their own protection.
Weak answerConcluding passkeys do not help.
Now defend it
As the defender, what would you monitor after the passkey rollout?
Logins that still use fallback methods by user group, recovery requests and their completion rate, registrations of new credentials shortly before sensitive actions, sign-count anomalies on device-bound keys, sessions reused from new devices, and attestation AAGUIDs outside the allowlist for administrators.
Primary references
References for the mechanisms discussed above, accessed 6 November 2026:
How this shows up in interviews
Expect "why are passkeys phishing-resistant?", "user presence versus user verification?", "synced versus device-bound?" and "what attacks remain after passkeys?". Strong answers explain the RP ID and origin binding, map synced and device-bound credentials to NIST assurance levels, and spend real time on recovery, fallbacks and session theft.
Say it in 30 seconds: "A passkey is a WebAuthn key pair for one site. The authenticator signs a fresh challenge together with browser-supplied data including the origin, and the credential is bound to the site's RP ID, so a phishing domain gets nothing usable, unlike codes or push prompts. User verification makes it two factors; synced passkeys are fine for AAL2, but AAL3 needs device-bound keys. Then I harden what attackers move to: remove phishable fallbacks for privileged users, design recovery carefully, and protect the session cookie issued after login."
Check yourself
Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.
1What is the RP ID rule in WebAuthn?
2What is the difference between the UP and UV flags?
3Why can synced passkeys not be used at NIST AAL3?
4Name two attack routes that remain after a passkey rollout.