Anti-Phishing

One-line relationship: this is C4 — preventing and detecting fake sites and mail that harvest credentials — and the concept that draws the sharpest line around what passkeys actually solve.

Phishing vs pharming

• Phishing — a fake site or message tricks the user into handing over credentials or approving something, voluntarily.
• Pharming — the user never sees anything suspicious; DNS or host-file poisoning silently redirects a correct-looking request to an attacker-controlled server.

Both end at the same place — a user interacting with an attacker-controlled endpoint while believing it’s genuine.

Why passkeys resist phishing (and what they don’t touch)

A WebAuthn credential is bound to the relying party’s origin at creation time; the browser will not release a signature to a different origin, full stop, regardless of how convincing the look-alike page is. That closes classic credential-harvesting phishing structurally, not by relying on the user noticing a wrong URL.

It does not close AiTM (adversary-in-the-middle) / reverse-proxy phishing — tools like Evilginx sit as a real-time reverse proxy between the victim and the genuine site, relaying every request and response transparently, including the login. The victim is actually talking to the real site the whole time; the attacker is just also watching and can steal the resulting session cookie once authentication completes. This defeats OTP and even some WebAuthn flows that don’t verify origin end-to-end at the RP, because the proxy simply passes through whatever challenge the real site issues. It does not defeat WebAuthn credentials that a browser correctly scopes to the proxy’s origin rather than the real one — the signature the proxy captures is bound to the wrong RP ID and is useless against the genuine site. The nuance matters when a client asks “aren’t passkeys phishing-proof?” — the honest answer is: proof against credential replay and look-alike domains, resistant but not immune to a live AiTM proxy, and not a defense against malware already on the device.

Email authentication — stopping brand spoofing at the source

DMARC, DKIM, and SPF are the mail-authentication layer that stops an attacker from sending email that appears to come from yourbank.com in the first place:

• SPF — a DNS record listing which mail servers may send for a domain.
• DKIM — a cryptographic signature on outbound mail, verifiable against a public key in DNS.
• DMARC — the policy layer tying the two together: what should a receiving server do (quarantine, reject) with mail that fails SPF/DKIM alignment.

Homograph and look-alike domains

Visually confusable domains (rnybank.com reading as mybank.com, or Cyrillic characters that render identically to Latin ones) are a low-cost, high-volume phishing vector. Brand and domain monitoring services scan for newly registered look-alikes and pursue takedown; this is detection-and-response, not a structural fix — it doesn’t stop the registration, only shortens the window before it’s caught.

What to take to the client

Anti-phishing is a portfolio, not a single control: passkeys close the biggest structural gap (credential replay via look-alike domains), DMARC/DKIM/SPF close the email-spoofing vector that starts most phishing campaigns, and domain monitoring shortens the exposure window for whatever gets through both. None of the three substitutes for the others.