Passkey & WebAuthn Lab
A passkey stops phishing not by being harder to guess, but by binding the credential to the origin — the authenticator signs over the RP ID, so a lookalike domain can never get a usable assertion. Work a queue of real identity-design scenarios and make the call: choose a passkey over a phishable OTP, push or password; spot the over-broad or mismatched RP ID, the missing user verification, or the phishable recovery fallback; and decide when a synced platform passkey is right versus when a privileged account needs a device-bound key. You are scored on catch rate against false positives — because blocking a passkey flow that already works, or forcing hardware keys where they do not belong, is its own failure. Make every call count.
The real job. More noise, a tighter clock.
Authentication decisions
Make the call on each scenario: the right passkey / OTP / password decision, the specific WebAuthn misconfig, or recognise the design is already sound.
#1
Consumer email, phished to death
A webmail provider authenticates with a password + an SMS code. Users are mass-phished through lookalike login pages and the SMS codes are being relayed. The team proposes replacing both factors with passkeys.
threat: bulk credential phishing via lookalike domains, SMS codes relayed in real time
#2
Bank adds TOTP against an AiTM kit
A bank is being hit by an attacker-in-the-middle phishing kit (a reverse proxy of the real login page). They plan to add a TOTP authenticator-app code as the second factor.
threat: AiTM reverse-proxy relays the password AND the TOTP code, then rides the authenticated session
#3
Admin portal, password only
An internal admin portal is protected by a username and password with no second factor. Several staff reuse the same password they used on sites that have since been breached.
threat: credential stuffing from reused, previously-breached passwords
#4
Lookalike domain asks for the passkey
A user holds a passkey for bank.example.com. A phishing email links to https://bank-secure.example-login.com, a pixel-perfect clone, which tries to trigger a WebAuthn login so the user "signs in with their passkey".
threat: lookalike phishing domain attempting to invoke the real bank’s passkey
#5
Wire transfer, no user verification
A payments app confirms high-value wire transfers with WebAuthn, but the ceremony is built with userVerification: "discouraged" — a single touch (user presence) completes it, with no PIN or biometric.
threat: a borrowed/unlocked laptop or shoulder-surf completes a transfer with a single tap
#6
Multi-tenant SaaS, one RP ID for all
A SaaS vendor serves each customer at a tenant subdomain: acme.vendorapp.com, globex.vendorapp.com, and so on. A developer sets the WebAuthn RP ID to vendorapp.com so "one passkey logs the user into any tenant".
threat: a passkey registered under tenant A is usable against tenant B — credentials cross tenant boundaries
#7
Photo app wants to mandate hardware keys
A consumer photo-sharing app serves non-technical users who swap phones often; account-recovery lockouts are already the top support cost. A reviewer wants to BAN synced passkeys and require everyone to buy a roaming hardware security key.
threat: usability / mass lockout for a low-value consumer population; phishing is the only real adversary
#8
Bank domain admins on synced passkeys
A regulated bank proposes protecting its domain administrators and break-glass accounts with synced passkeys stored in a consumer password manager, synced to each admin’s personal cloud account.
threat: the crown-jewel private key is replicated across the sync fabric and recoverable via a personal cloud-account reset
#9
Registration ceremony keeps failing
A new passkey rollout throws a SecurityError at registration in production. The app is served at https://app.example.com, but the RP ID in the create options is set to login.example.com. An engineer suggests "just set the RP ID to example.com to make it work everywhere".
threat: a broken ceremony tempts the team to loosen the RP ID to a broad parent
#10
Number-matching push, believed phish-proof
An enterprise rolled out number-matching push MFA and the security team now describes it as "phishing-resistant". They are being targeted by an AiTM reverse-proxy campaign.
threat: AiTM proxy relays the login; the user approves the matched number, then the proxy steals the session
#11
Workforce IdP, spear-phished staff
A company’s SSO identity provider is the front door to everything. Employees are being spear-phished. The proposal: passkeys as the primary factor AT THE IDP, UV required, platform authenticators enrolled with a roaming key as backup.
threat: targeted spear-phishing of employees to pivot into the SSO estate
#12
Pentest claims "passkey phishing" works
A clean passkey login (RP ID and origin both bank.example.com, UV required). A pentester reports they "phished the passkey" by cloning the page at bank-login-verify.com and scripting a WebAuthn call with rpId "bank.example.com" from that page.
threat: a cloned page scripting a WebAuthn request that claims rpId bank.example.com from an unrelated origin
#13
Shared kiosks on the hospital floor
Clinicians sign into an EHR from shared ward workstations and from their own phones. Patient records are the asset. The team wants synced passkeys everywhere for convenience.
threat: a synced personal passkey on shared/clinician-owned devices, with no control over which authenticator model holds the key
#14
Admin console, UV "preferred"
A cloud admin console uses passkeys with userVerification: "preferred". Many admins authenticate from desktops with a plug-in security key that has no PIN set, so the ceremony silently completes with user presence only.
threat: UV "preferred" falls back to presence-only on keys with no PIN, so a stolen/left-plugged key logs in
Right calls vs. false positives
Decide each scenario, then grade. So far 0/14 called, 0/11 problems caught, 0 false positive(s).
How it is scored
Catch rate = scenarios that need a fix given the exact right call.
A false positive (flagging a sound passkey flow, or over-engineering a benign one with hardware keys) takes an extra hygiene bite — an identity reviewer who blocks working controls is as useless as one who misses holes.
Harder tiers add subtler scenarios and deliberate traps: a phishing "finding" that cannot actually work, UV set to preferred, and a synced-vs-device-bound call that cuts the other way.
Why passkeys are phishing-resistant
The browser only offers a credential whose RP ID matches the serving origin, and the authenticator signs over that RP ID (the origin travels in the signed data). A lookalike domain can neither retrieve the real credential nor forge a usable assertion — the private key never leaves the authenticator and nothing phishable is typed.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based passkey & WebAuthn lab: work a queue of ~20 identity-design scenarios and make the right call on each — passkey vs OTP vs password, the specific WebAuthn misconfig, or "the design is already sound".
- It teaches the real FIDO2 decisions: why passkeys are phishing-resistant (the authenticator signs over the RP ID and origin, so a lookalike domain cannot get a usable assertion), platform vs roaming authenticators, and synced vs device-bound credentials.
- Problems seeded across the queue: a phishable OTP/push or SMS recovery fallback, a password left standalone beside a passkey, an over-broad or mismatched RP ID, missing user verification, and privileged accounts that need a device-bound key with attestation.
- You are graded on catch rate weighed against false positives — flagging a sound passkey flow, or over-engineering a benign one with hardware keys, takes an extra hygiene penalty, because blocking controls that work is its own failure.
- Pure client-side: nothing is uploaded, no authenticator or crypto is invoked, and after grading every scenario shows exactly why the right call is right.
Frequently asked questions
What is the Passkey & WebAuthn Lab?
A free, in-browser exercise where you work a queue of realistic identity-design scenarios — a login being phished, a multi-tenant SaaS RP ID, a high-value action without user verification, a privileged account on a synced key — and make one call on each: choose the phishing-resistant factor (a passkey) over a phishable one (OTP, push, password), name the specific WebAuthn misconfiguration, or recognise that the design is already correct and the attack cannot work. You are scored on how many real problems you catch versus how many sound designs you wrongly flag.
Why are passkeys phishing-resistant?
A passkey is a WebAuthn credential whose private key never leaves the authenticator. The browser will only offer a credential whose RP ID matches the serving origin’s effective domain, and the authenticator signs over that RP ID while the origin is carried in the signed clientDataJSON. So a lookalike domain can neither retrieve the real site’s credential nor forge an assertion the real site will accept — and the user never types a secret that could be relayed. That origin binding is the structural reason a passkey defeats the attacker-in-the-middle phishing that relays passwords, TOTP codes and push approvals.
What is the difference between synced and device-bound passkeys?
Synced (multi-device) passkeys replicate the private key through a provider’s sync fabric — Apple, Google or a password manager — so they survive a lost phone and are recoverable through the user’s cloud account; they are ideal for broad consumer populations. Device-bound (single-device) FIDO2 keys are non-exportable and live only on one authenticator, which is what you want for privileged, regulated or crown-jewel accounts, usually paired with enterprise attestation so the Relying Party can confirm an approved authenticator model. The lab makes you choose correctly in both directions, including a trap where mandating hardware keys for ordinary consumers is over-engineering.
Does it run real WebAuthn or touch my authenticator?
No. Nothing is uploaded, no authenticator, biometric or security key is invoked, and no crypto runs. The scenarios are authored, realistic decoded descriptions bundled with the page, and it runs entirely in your browser — no account, no install, nothing sent anywhere.
Who is it for?
IAM and application-security engineers rolling out passkeys, architects choosing between OTP, push and WebAuthn, and anyone prepping for a security interview who wants to feel why TOTP and number-matching push are still phishable, why an SMS recovery path defeats a passkey, why an over-broad RP ID lets a credential cross tenants, and when a synced passkey is exactly right versus when a device-bound key is required.