IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Adversary-in-the-middle (AiTM) phishing
Maya gets an email: "Unusual sign-in detected. Verify now." The login page looks perfect. She types her password and her one-time code. Both are correct, and both go to an attacker. Your goal: explain why codes fail here and why a passkey does not.
- A fake page can sit in the middle and pass your password and code on, live.
- Anything you can read and type, the attacker's page can pass on too.
- The padlock does not prove who owns the page.
- A passkey signature only works for the real site, so the relay fails.
A copy of the page that looks real
Maya trusted the page. It was a look-alike page: a copy of the real login, on a web address a few letters off. Behind it sits an adversary-in-the-middle (AiTM) proxy. A proxy is a server that stands between two sides and passes messages along. This one passes every request and answer, live.
To Maya, it feels like the real login. To the real site, it looks like Maya's browser. Neither side can see the proxy. It is like a two-way mirror.
In Spotting phishing and fake logins you learned to read the link. That still helps. But this fake is live: it shows the real site's own pages, so nothing on the screen looks wrong.
Everything you type is passed on
The proxy sends the password to the real site at once. The real site asks for a second factor. The proxy shows that request to Maya. She types the code from her authenticator app. The proxy passes it on while it is still valid.
The real site is satisfied. It sends back a session cookie: a small note your browser keeps so you stay signed in. The proxy keeps a copy. In the attacker's browser, that cookie is Maya's session. No password or code is needed again.
Why every shared secret fails
Anything Maya can read and type, the proxy can read and type too. A password is a shared secret. So is a code sent by text message. So is a TOTP app code: it lasts about 30 seconds, but a live proxy uses it inside that time.
More secrets only give the proxy more to pass along. What stops this attack is different in kind, not in number.
The padlock only means the connection to that page is private. It does not say who owns the page. A look-alike domain can have a valid certificate. Checking the address by eye helps a little, but tired people miss a swapped letter. It is a weak backstop, never the plan.
What stops it: a passkey
A passkey works in a different way. You do not type a secret. Your device keeps a private key and signs a challenge from the site. The signature is tied to the origin: the exact domain in the address bar.
On the look-alike page, the browser uses the look-alike's origin, not the real site's. So the signature is made for the wrong party, and the real site rejects it. The proxy has nothing to pass on. This is what phishing-resistant means.
A passkey only protects people who use it. A proxy can hide the passkey option, so the user sees only weaker ones. For important accounts, remove the weaker sign-in paths.
Backstops: weaker, but worth having
🔗 Bind the session to the device
Device binding ties the session to a private key on the real device. DBSC does this for browser cookies. DPoP and mTLS do it for OAuth tokens. A relayed session cannot prove it holds the key, so it is useless to the attacker (see Session hijacking, Stolen-token defenses II).
🚨 Detect it afterwards
Impossible travel and new-device signals can flag a relayed session soon after it starts. Then you can revoke it (Go deeper below shows what the log tells; see Detection engineering).
Go deeper: What the real site's log shows
The real site cannot see the proxy. But the sign-in log still shows its footprints. Compare two sign-ins for Maya. Both have the right password and a valid code.
| Log field | Maya at home | Through a proxy |
|---|---|---|
| Network | Her home broadband, in her city | A cloud hosting network, often in another country |
| Browser and device | The one she always uses | A different one, never seen for her |
| Gap since the code | She works as usual | Minutes later, the same session reads mail or changes a payee |
Each sign differs from Maya's own habit, so this is how you spot it. One sign alone can be a harmless trip. Several together are the tell. A bound session removes the problem, because the copied cookie is refused.
Go deeper: Standards and token binding
NIST SP 800-63B-4 (final, July 2025) sets rules by assurance level. At AAL2 a service must offer at least one phishing-resistant option. At AAL3 it must require one. CISA calls phishing-resistant MFA, meaning FIDO/WebAuthn or smart cards, "the gold standard". Read the full mechanism in Passkeys & WebAuthn.
DPoP is defined in RFC 9449. Mutual TLS for OAuth is defined in RFC 8705.
🧪 Interactive lab — enable JavaScript to play with this one.
Check that your own login is phishing-resistant. Grade your passkey and WebAuthn setup with Passkey Check. Then check that your session cookies are bound and hardened with Cookie Check.