Phishing Resistance

Phishing resistance

Most multi-factor authentication still ships the secret to whoever asks. A modern phishing kit proxies your real login page, catches the one-time code, and replays it within seconds. The only durable fix is a credential the browser refuses to hand to the wrong origin, so factor choice, not the presence of "MFA," decides whether you survive.

Method

1. Prefer origin-bound WebAuthn credentials. Register passkeys or FIDO2 hardware keys through the WebAuthn API. The authenticator signs a challenge scoped to your exact RP ID, so a credential minted for example.com produces nothing usable at examp1e.com. That binding is what "phishing-resistant" literally means.
2. Rank factors by phishability, not by count. Passkeys and FIDO2 keys resist relay; TOTP apps and push approvals do not; SMS one-time codes are worst, exposed to SIM swap on top of relay. A reverse-proxy kit like Evilginx forwards any code-based factor live, so "we have MFA" is not "we resist phishing."
3. If push must stay, require number matching and cap prompts. Show a two-digit number on the login screen that the user types into the app, and rate-limit prompts per account. A bare approve/deny push trains users to tap approve and falls to MFA-fatigue bombing.
4. Verify origin and challenge server-side on every assertion. Scope rpId to your registrable domain, set userVerification: 'required' for step-up, and reject any assertion whose origin or challenge does not match what you issued. Skipping the origin check reopens the exact hole WebAuthn closed.
5. Harden recovery, because that is what gets phished now. Never let an SMS code or a security question reset away a passkey. Require a second registered authenticator, an out-of-band verified process, or a signed recovery code issued at enrollment.
6. Register two authenticators at enrollment. Require a backup key or a synced passkey so a lost phone does not force the user onto a weak fallback. Store each credential ID and let users name and revoke them.
7. Use attestation where assurance matters. For regulated or high-value access, request attestation to confirm the authenticator model meets your bar (hardware-bound, FIPS) and gate that path at AAL3 per NIST SP 800-63B.

Litmus tests

• Tested through a proxy, does a credential registered on your real origin fail to authenticate against a look-alike domain?
• If an attacker phishes a live TOTP or push approval, can they reach the account, and why is that factor still allowed for sensitive actions?
• Can account recovery silently downgrade a passkey user back to SMS, and who signed off on that path?

Boundaries

This skill covers resisting credential phishing at the moment of authentication. The password hashing, throttling, and session rotation baseline lives in authn-design; federated sign-in trade-offs belong to oauth-flows; and what a user may do once authenticated is authz-design.