Security
What makes authentication phishing-resistant?
The technical property that makes an authenticator phishing-resistant — verifier-name binding — why codes and push fail it, and what passkeys change.
The short answer
Authentication is phishing-resistant when the authenticator itself refuses to produce a usable response for the wrong website. NIST SP 800-63B calls this verifier name binding (or channel binding): WebAuthn authenticators sign over the site's origin, so a look-alike domain cannot obtain a valid signature. Anything the user reads and types — passwords, one-time codes — fails this test, because the user can be persuaded to type it into the wrong page.
Sources last reviewed .
Why codes are phishable
Adversary-in-the-middle phishing kits proxy the real site: the victim enters password and code on the fake page, the kit relays them instantly, and captures the resulting session cookie. Nothing in a six-digit code tells it which site it was typed into.
What changes with passkeys
The browser supplies the origin to the authenticator, and the credential is scoped to the relying party ID. A proxy on another domain cannot ask for a credential for the real domain. The user cannot be talked into bypassing this because they never handle the secret.
What it does not solve
Phishing-resistant sign-in does not protect a session cookie stolen after sign-in, and does not help if recovery falls back to a phishable method. Pair it with session controls and a recovery process of comparable strength.
In Authreads
How this applies to Authreads
Passkeys are Available on hosted login and through the API. Tokens report a user-verified passkey sign-in in amr and acr, and a relying party can require one with acr_values=urn:authreads:acr:phr.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.