pattern

Phishing-Resistant Authentication

also called Origin-Bound Authentication, Unphishable MFA

Authentication whose response cannot be replayed at a site other than the one it was produced for, because the authenticator signs the requesting origin rather than releasing a secret the user could pass on.

fido2webauthnmfaphishingcloudflaretwilio

Multi-factor authentication is usually counted rather than characterised. Password plus SMS is two factors. Password plus a time-based code is two factors. Both can be forwarded by a person who has been convinced to forward them, which is the entire technique of a real-time phishing proxy: a page that collects the password and the code and uses them on the genuine site within 30 seconds, inside the code's validity window.

Phishing resistance is a different property from factor count. The authenticator holds a private key, and the signature it produces covers the origin of the site making the request. There is no secret to relay, and a signature produced for a lookalike domain does not verify at the real one.

Why it matters

The two outcomes in 2022 make the point better than any argument. The same SMS campaign reached employees at Twilio and at Cloudflare. Twilio reported unauthorised access to data belonging to around 209 of its roughly 270000 customer accounts. Cloudflare reported that at least 76 employees received the messages, that three entered credentials, and that no systems were compromised, because every employee authenticated with a FIDO2 hardware key. Cloudflare's account also describes the phishing page relaying the one-time code in real time and pushing a download of the remote access tool AnyDesk.

Both companies' humans failed. Only one company's authentication did. Training is worth doing and it is not a control: this campaign succeeded against trained employees at a security company.

Implementation patterns

  • Hardware security keys or platform authenticators for every employee, enrolled against the identity provider, with the provider configured to require the phishing-resistant method rather than merely to offer it.
  • No relayable fallback. If a lost key can be replaced by an SMS code from a help desk, the attacker calls the help desk. Recovery is in-person, manager-attested, or uses a second registered key.
  • Two keys per person from the start, so loss is an inconvenience rather than an incident and the recovery path is rarely exercised.
  • Device-bound session tokens, so a stolen session cookie is not a path around the key.
  • Extend it to the paths people forget: VPN, break-glass accounts, cloud console, code hosting and the identity provider's own administrative interface.

Industry example

Cloudflare's public account of the July 2022 campaign is the clearest documented case: a phishing page cloned the identity provider's login, collected credentials and codes from three employees, and failed at the hardware key step because the signature is bound to the origin. Twilio's disclosure of the same campaign, without that control, describes customer data exposure. The pair is unusually instructive because the attacker, the technique and the timing are held constant.

Failure scenarios

  • A relayable recovery path, which becomes the attack rather than a defence.
  • Partial rollout, where one legacy application still accepts a password and a code, and that application holds a session that reaches everything else.
  • Push-approval fatigue where a push-based factor is retained alongside, and repeated prompts eventually get approved.
  • Session theft after authentication, which no login-time control addresses; this is why token binding matters.
  • Shared service accounts that cannot hold a key and are therefore exempt, which is where the attacker goes next.

Trade-offs

Choose Gains Pays
Hardware keys, no fallback Real-time phishing proxies stop working Cost per employee, a lost-key process, and hardware logistics
Platform authenticators No hardware to ship, same origin binding Tied to device lifecycle; recovery on device loss needs design
TOTP Cheap, works anywhere Relayable, so it does not address the threat that actually occurs

The honest cost is roughly two keys per person plus a recovery process that requires human attestation. It scales with headcount, so the case is strongest where many employees can reach customer data.

When not to use it

For customer-facing consumer authentication, mandating hardware keys costs conversions and locks out people who lose them, so the usual answer is passkeys with a carefully designed recovery path rather than a hardware mandate. For a company of a dozen people whose surface is a handful of software-as-a-service accounts, enforcing the phishing-resistant method at the identity provider covers nearly everything and a broader programme is premature.

Interview question

Q: Your board asks why the company should spend on hardware keys when it already mandates multi-factor authentication. Give the argument in one minute, then tell me what you would do about the help desk.

What a strong answer covers: that factors should be ranked by relayability rather than counted · the mechanism of origin binding versus a shared short-lived secret · the 2022 Twilio and Cloudflare pair as evidence that the difference is decisive · that recovery and enrolment must be as strong as the primary path or they become the attack · session-token binding, because login-time controls do not cover stolen sessions · and the cost, stated plainly, with the scope where it pays first.

Quick check

Quiz: Why does a real-time phishing proxy defeat TOTP but not a security key? Because TOTP is a secret the user can be induced to forward, while the key's signature covers the requesting origin and does not verify at the attacker's domain.

Flashcard: Rank MFA by what? Relayability, not factor count. Password plus SMS and password plus TOTP are both two factors and both fall to a real-time proxy.