Skip to content

CONCEPT Cited by 1 source

Phishing-resistant authentication

Definition

Phishing-resistant authentication is authentication whose credentials cannot be replayed against a proxy site because the authenticator cryptographically binds the sign-in to the origin (and, optionally, the TLS channel) it was registered against. A reverse-proxy phishing kit that terminates TLS at a lookalike domain and forwards requests to the real site cannot coax the browser-side authenticator into producing a valid assertion for the real origin, because the origin is part of the challenge the authenticator signs.

The canonical in-production realisations are FIDO2 / WebAuthn / Passkeys. The security model has two load-bearing properties:

  • Origin binding — the challenge signed by the authenticator includes the origin the browser is actually on. A malicious proxy serving members-x.com cannot produce an assertion that the real x.com will accept.
  • Channel binding (optional, stronger form) — the challenge additionally binds to the specific TLS connection, defeating certain classes of MITM on the TLS path.

Cf. Fly.io's 2025-10-08 postmortem:

"Phishing-resistant authentication works by mutual authentication (or, if you're a stickler, by origin- and channel-binding). Phishes are malicious proxies for credentials. Modern MFA schemes like FIDO2 break that proxy flow; your browser won't send real credentials to the fake site." (Source: sources/2025-10-08-flyio-kurt-got-got)

What it is not

  • TOTP / SMS OTP. The user reads a code off a screen and types it into whatever site is in front of them. A reverse- proxy phishing kit captures the code and replays it to the real site within the 30-second TOTP window. Phishable.
  • Push-notification approval. The user sees "approve sign- in?" and taps yes. The push is usually tied to an account and an attempt, not an origin. A reverse-proxy kit triggers a real sign-in to the real site and waits for the user to approve. Phishable. "MFA fatigue" attacks exploit this by sending repeated prompts until the user approves.
  • Password + any of the above. Still phishable end-to-end.
  • Password managers alone. See patterns/password-manager-as-phishing-guardrail — the browser plugin's domain-matching refusal to autofill is a poor-man's origin check, but is defeated by manual copy-paste, which is exactly how the Fly.io incident happened.

Why phishing training is not a substitute

Fly.io's postmortem canonicalises the claim that user training alone does not defeat phishing at scale:

"Contrary to one popular opinion, you don't defeat phishing by training people not to click on things. I mean, tell them not to, sure! But eventually, under continued pressure, everybody clicks. There's science on this. The cool kids haven't done phishing simulation training in years. What you're supposed to do instead is use phishing-resistant authentication." (Source: sources/2025-10-08-flyio-kurt-got-got, citing the OAKLAND 2025 paper "Understanding the Effectiveness of Enterprise Phishing Training" by Ho et al.)

The structural claim is: user-side vigilance is a bounded resource; attacker iteration is unbounded; eventually the attack lands. The fix is to make the user-side decision cryptographically irrelevant — even if the user clicks the phish, the authenticator refuses to sign for the wrong origin.

Why this matters for system design

Phishing-resistant auth is one of the few security primitives that is:

  • Cryptographic, not behavioural. The control does not depend on user judgement.
  • Cheap to adopt once available at the IdP layer. If your IdP (Google Workspace, Okta, Microsoft Entra, etc.) supports passkey / FIDO2, enabling it is configuration.
  • Amplified by SSO. If everything downstream is behind one IdP, making that one IdP phishing-resistant protects all downstream apps transitively — see patterns/phishing-resistant-mfa-behind-idp.

The coverage-gap failure mode is: anything not behind the IdP is still phishable. Fly.io's incident is the canonical instance — all infra was behind Google SSO, but the Twitter account was a legacy shared account outside that regime.

Seen in

  • Fly.io Kurt Got Got (2025-10-08) — canonical wiki instance. Names the mutual-authentication / origin-and-channel-binding mechanism explicitly; cites the phishing-training-ineffectiveness paper; positions FIDO2/WebAuthn/Passkeys as the fix; names "everything behind an IdP" as the operational pattern (sources/2025-10-08-flyio-kurt-got-got).
  • Cloudflare EmDash (2026-04-01) — passkey-by-default as a "structurally removes the dominant class of authentication attacks" framing (sources/2026-04-01-cloudflare-emdash-wordpress-spiritual-successor).
Last updated · 517 distilled / 1,221 read