Phishing-resistant sign-in

Phishing-resistant sign-in changes what an impostor can obtain from a convincing login page. NIST defines phishing resistance as preventing disclosure of usable authentication secrets to an impostor without depending on the user's vigilance. It says passwords and manually entered one-time codes are not phishing-resistant because an impostor can relay them into a real session.¹

WebAuthn and FIDO2 use cryptographic credentials bound to the service's authenticated domain. The WebAuthn specification says a public-key credential can authenticate only to the relying-party identifier for which it was registered, and services must reject unexpected origins.² The important property is not whether a fake page looks convincing. It is whether the credential works for that page's domain.

The diagram contrasts a code that can be relayed with a credential tied to its registered site.

<svg viewBox="0 0 560 300" role="img" aria-labelledby="signin-title" font-family="system-ui, sans-serif">
  <title id="signin-title">Relayed codes and domain-bound credentials</title>
  <defs>
    <marker id="arrow" markerWidth="8" markerHeight="8" refX="7" refY="4" orient="auto">
      <path d="M0,0 L8,4 L0,8 Z" fill="currentColor"/>
    </marker>
  </defs>
  <text x="20" y="25" font-size="18" font-weight="700" fill="currentColor">Manually entered code</text>
  <rect x="20" y="45" width="140" height="60" rx="8" fill="none" stroke="currentColor" stroke-width="2"/>
  <text x="90" y="70" text-anchor="middle" font-size="14" fill="currentColor">Person enters</text>
  <text x="90" y="90" text-anchor="middle" font-size="14" fill="currentColor">a code</text>
  <line x1="160" y1="75" x2="205" y2="75" stroke="currentColor" stroke-width="2" marker-end="url(#arrow)"/>
  <rect x="210" y="45" width="140" height="60" rx="8" fill="none" stroke="currentColor" stroke-width="2"/>
  <text x="280" y="70" text-anchor="middle" font-size="14" fill="currentColor">Impostor</text>
  <text x="280" y="90" text-anchor="middle" font-size="14" fill="currentColor">captures code</text>
  <line x1="350" y1="75" x2="395" y2="75" stroke="currentColor" stroke-width="2" marker-end="url(#arrow)"/>
  <rect x="400" y="45" width="140" height="60" rx="8" fill="none" stroke="currentColor" stroke-width="2"/>
  <text x="470" y="70" text-anchor="middle" font-size="14" fill="currentColor">Relay reaches</text>
  <text x="470" y="90" text-anchor="middle" font-size="14" fill="currentColor">real session</text>
  <text x="20" y="155" font-size="18" font-weight="700" fill="currentColor">Domain-bound credential</text>
  <rect x="20" y="175" width="140" height="60" rx="8" fill="none" stroke="currentColor" stroke-width="2"/>
  <text x="90" y="200" text-anchor="middle" font-size="14" fill="currentColor">Person starts</text>
  <text x="90" y="220" text-anchor="middle" font-size="14" fill="currentColor">credential sign-in</text>
  <line x1="160" y1="205" x2="205" y2="205" stroke="currentColor" stroke-width="2" marker-end="url(#arrow)"/>
  <rect x="210" y="175" width="140" height="60" rx="8" fill="none" stroke="currentColor" stroke-width="2"/>
  <text x="280" y="200" text-anchor="middle" font-size="14" fill="currentColor">Impostor</text>
  <text x="280" y="220" text-anchor="middle" font-size="14" fill="currentColor">domain appears</text>
  <line x1="350" y1="205" x2="395" y2="205" stroke="currentColor" stroke-width="2" marker-end="url(#arrow)"/>
  <rect x="400" y="175" width="140" height="60" rx="8" fill="none" stroke="currentColor" stroke-width="2"/>
  <text x="470" y="200" text-anchor="middle" font-size="14" fill="currentColor">Domain binding</text>
  <text x="470" y="220" text-anchor="middle" font-size="14" fill="currentColor">blocks relay</text>
</svg>

Figure: Entered codes can travel to a real session, while domain binding keeps a credential tied to its registered site.

This protection has worked in a documented organizational incident. Cloudflare employees entered usernames and passwords into a fraudulent page, but attackers could not satisfy the company's FIDO2 security-key requirement.³ That incident demonstrates the control against one attack path rather than its effect on ordinary consumer losses.

Correct protocol design does not ensure that every surrounding process is secure. Research on passkey-enabled websites found serious implementation vulnerabilities among sites subjected to detailed testing.⁴ Microsoft has also observed intrusions where passkey support was used as a pretext to direct people into alternate device-code or intermediary flows rather than to break a passkey.⁵

Phishing-resistant sign-in has not been evaluated for its effect on fraud losses among ordinary retail-bank customers. It remains a recommended account control, not a measured guarantee against consumer loss.

Boundary. Domain binding protects the sign-in exchange for which it is correctly implemented. It does not establish that a caller is genuine, that a requested payment is safe, or that recovery and enrollment paths are equally strong. The judgment therefore does not extend automatically to session theft, device-code flows, weak website implementations, or other routes that bypass the bound credential.