"Passkeys are a trap," said a viral post. Why a 2FA code can be phished and a passkey can't

What a passkey is, and what it is not

A passkey is a login credential that replaces a password with a key pair. When you create one, your phone, laptop or password manager generates two keys for that one website. The private key stays with you, inside the device or the password manager that syncs it between your own devices. The website only ever receives the public key.

Signing in is a challenge and a response. The site sends a random challenge; your device signs it with the private key after you unlock it with a fingerprint, face or PIN; the site checks the signature against the public key it stored. Nothing you could type is involved, and nothing the site stores would let anyone log in if it leaked.

Passkeys are not a new invention so much as a friendly name. Under the hood they are WebAuthn credentials, a W3C standard, used with the FIDO Alliance's protocols. The WebAuthn specification itself barely uses the word "passkey"; it talks about discoverable credentials, authenticators and relying parties.

Why a six-digit code can be relayed

The alternative the "trap" post recommends is a password plus a time-based one-time password (TOTP), the six-digit code from an authenticator app. TOTP is defined in RFC 6238. The app and the site share a secret seed when you set it up, and each side computes the same code from that seed and the current time, in steps of 30 seconds by default.

That design protects against a stolen password being reused later. It does not protect against a live relay. A phishing kit such as Evilginx runs a lookalike site that sits between you and the real one: it shows you the real site's pages, and forwards whatever you type, password and then code, to the real site as you type it. The real site sees a correct password and a fresh code, logs the session in, and the kit keeps the session cookie. Thirty seconds is far longer than the relay needs.

This is what happened to Troy Hunt, who runs Have I Been Pwned, on 25 March 2025. In his own account, he followed a link to a lookalike page on mailchimp-sso.com, entered his credentials (which his password manager, 1Password, did not autofill) and his one-time code, and the page hung. Moments later Mailchimp alerted him to a login and a mailing list export from an IP address in New York. The export held about 16,000 records, of which 7,535 were people who had unsubscribed. Hunt's own conclusion was that OTP-based two-factor is "completely useless" against an automated phishing attack that relays the code as soon as it is entered.

Two details from his write-up matter for what follows. He was jet-lagged and tired. And he ignored the missing autofill because real services often log you in on a different domain from the one you saved, so a password manager failing to match is not unusual.

How the browser ties a passkey to one domain

The part the video calls "your browser checks" is written into the WebAuthn specification, and it is what makes a passkey different from anything you type.

• Every passkey is created for a relying party ID (RP ID), which is a domain such as mailchimp.com.
• When a page asks to sign in with a passkey, the browser compares the RP ID it asks for with the page's own domain. The RP ID must equal the page's domain or be a registrable suffix of it (so login.mailchimp.com may ask for mailchimp.com). Otherwise the browser throws a SecurityError and the authenticator is never consulted.
• A page on mailchimp-sso.com therefore cannot ask for the mailchimp.com passkey. It can only ask for passkeys made for mailchimp-sso.com, and you have none.
• Even if a page could forward a challenge, the browser writes the page's real origin into the signed data (clientDataJSON), and the authenticator signs a hash of the RP ID (rpIdHash). The real site checks both, so a signature produced on the wrong domain fails at the server too.

There is one deliberate exception. Level 3 adds related origins: a site with several country or brand domains can publish a JSON file at https://<rp id>/.well-known/webauthn listing the origins allowed to use its passkeys. Because the file has to be served from the real domain, a phishing site cannot add itself to it.

None of this depends on you noticing anything. That is the whole point of the comparison in the video between a code you can be talked into typing and a key the browser will not hand over.

What the "trap" post actually argues

The post is written for non-technical readers and makes a different argument from the one about phishing. Its case, in its own order:

• Passkeys come in many kinds. Copyable or not, transferable or not, stored in software or in a secure chip, requiring a person to be present or not, requiring biometrics or a PIN or not. The author calls the specification a parts catalogue and says one name for all of them confuses users.
• Your passkey software reports which kind it is, through flags in the authenticator data. The specification defines these bits: UP (user present), UV (user verified), BE (backup eligible, which is what the post calls copyable) and BS (backup state). Software can set them however it likes.
• Attestation is the exception. A site can ask for an attestation statement, a certificate chain from the authenticator's maker. The post says this proves an approved passkey manager, operating system and firmware are in use, and "can't be faked".
• The fear is that sites will gradually start requiring attested passkeys. The post imagines that locking out Linux, phones running a custom operating system such as LineageOS, self-written software, and shared logins on services like Netflix, and it extends the worry to platform control more broadly.
• What it concedes. It says attested passkeys are "not yet required on most websites", it labels its predictions as predictions, and its addendum agrees passkeys are domain-bound and resist man-in-the-middle attacks.
• What it recommends instead: TOTP, and hardware security keys such as a YubiKey.

What the rebuttal says, and where both overreach

Scott Helme, who runs WhyNoPasskeys.com and maintains an open-source passkeys library, answers the attestation argument directly:

• The synced passkeys most people use (iCloud Keychain, Google Password Manager, 1Password, Bitwarden) return an attestation format of none. He says he tested this with his own library.
• A consumer site that demanded attestation would lock out nearly all of its own users, and guidance for consumer sites has long been not to request it.
• When attestation is present, it identifies the make and model of the authenticator through its AAGUID, a 128-bit identifier, backed by the maker's certificate.
• YubiKeys are the authenticators that do attest, so the post's recommendation points towards attestation rather than away from it.
• TOTP can be typed into the wrong site, which is the problem passkeys solve.

Both sides go further than the specification on one point. The trap post says attestation proves the operating system and firmware; for the common formats it identifies the authenticator, not the whole device. Helme says attestation says nothing about your OS or whether your phone is rooted; but the specification still describes an android-safetynet format, now marked deprecated, whose statement includes "statements about the health of the platform". So: today's attestation mostly names the authenticator, one deprecated format did report device health, and either way the passkeys most people hold send none. That reading is ours, from the specification's text.

The video leaves attestation's details out for that reason, and states the post's worry in its own terms.

What the video left out

Account recovery and portability. The post's deeper complaint is control: with a password you choose where it is written down. Passkeys move that to the provider that syncs them. Helme's answer is to pick a provider that lets you move credentials out. Neither post settles how well that works across providers today, and the video does not try to.

Copyable passkeys are a real thing. The trap post's author generated a passkey with open-source software and emailed it to a friend, and both could sign in. That is a software credential with backup eligibility set, and it is exactly why the post says the flags are self-reported.

Two-factor still beats a password alone. Nobody in this debate argues for passwords on their own. The disagreement is about what comes next: a code that can be relayed, or a passkey that cannot.

Terms

Passkey

A WebAuthn credential, a key pair made for one website, unlocked on your device by a fingerprint, face or PIN.

WebAuthn

The W3C standard browsers implement for passkeys and security keys.

Relying party (RP) and RP ID

The website that accepts the passkey, and the domain the passkey is bound to.

TOTP

Time-based one-time password, RFC 6238. The six-digit code an authenticator app computes from a shared seed and the time, every 30 seconds by default.

Phishing kit (adversary in the middle)

Software such as Evilginx that sits between you and a real site, relays what you type, and keeps the logged-in session.

Attestation

A signed statement from an authenticator's maker about what created a credential. Optional, and none for most synced passkeys.

AAGUID

The 128-bit identifier an authenticator reports for its make and model.

Authenticator data flags

Bits the authenticator sets on each response, including UP, UV, BE and BS.

Synced versus device-bound passkey

A synced passkey is copied between your devices by a password manager; a device-bound one never leaves its chip.

Related origins

A WebAuthn Level 3 feature that lets one RP ID be used from a published list of the owner's other domains.

Questions

// further reading

• Passkeys Are Not a Trap ↗: Scott Helme's rebuttal, the source this video credits.
• Passkeys are a trap. Do not use them. ↗: the post that started the debate, with its footnotes and addendum.
• A Sneaky Phish Just Grabbed my Mailchimp Mailing List ↗: Troy Hunt's own account, updated as he learned more.
• Web Authentication Level 3 ↗: the specification, including RP ID rules, flags and attestation formats.
• RFC 6238 ↗: the TOTP standard behind six-digit codes.