The Unphishable Login

Phishing succeeds when a human is convinced to authenticate to the attacker's endpoint while believing it is the real one. Read that sentence for what it omits. It says nothing about email — the lure can be a text message, a search advertisement bidding on your own brand name, a calendar invitation, or a QR code taped over the real one in a hotel lobby. It says nothing about exploits, because there is nothing to exploit: the victim types a valid credential into a page they chose to visit, over a connection their browser correctly reports as secure. The compromise is in the target of an otherwise perfectly executed authentication.

This matters because it tells you which defenses are in the right category. An email gateway that quarantines the lure works on the delivery, so its effectiveness is a function of how many delivery channels exist — and the number keeps growing. Endpoint detection works on execution, so it has nothing to detect. Even a browser warning is a race between a freshly registered domain and a reputation system that has not seen it yet. None of these controls touch the actual mechanism, which is why each of them degrades gracefully into “usually works” rather than “cannot be beaten.”

Here is the test the rest of this course runs on. A credential is phishable exactly when its normal use consists of the user transferring a value or an approval that the attacker can then reuse against the real server. Call it the handover test. It has two clauses and both must hold: the user must be the one moving the thing, and the thing must retain its power in the attacker's hands.

Apply it to a password: the user reads it out of their head or their manager and types it into a box, and the string works identically wherever it is typed. Both clauses hold — phishable. Apply it to a six-digit authenticator code: the user reads it off a screen and types it into a box, and for the next twenty seconds it works anywhere. Both clauses hold — phishable, on a shorter clock. Apply it to a push notification: the user does not transfer a string, but they transfer an approval, and that approval attaches to whichever login session prompted it, which may not be theirs. Both clauses hold — phishable.

The test's value is that it is predictive rather than historical. When a vendor demonstrates a new factor — a voice confirmation, a one-tap email magic link, a “tap your card to your phone” flow — you do not need an incident to classify it. You ask two questions. What exactly does the user hand over? And is that thing still good if a stranger holds it? Two answers, and you know which side of this course's line the factor falls on.

Three attacks routinely get filed under “phishing” in incident reports, and each needs a different control. Separating them is not pedantry; it decides what you buy and what you report.

Two of these are worth holding onto. Credential stuffing is the mirror image of phishing: the credential is stolen from a third party and the legitimate user is never involved, which is why a password manager and unique passwords defeat it completely and do nothing whatsoever for phishing. Session hijacking matters for a different reason — it is the tail of the phishing attack you will meet in Module 3. Once an attacker holds a session cookie, the authentication ceremony is finished and irrelevant; hardening the front door does not evict someone already inside.

Awareness training is real. Programs that run it well see click rates fall, often by an order of magnitude, and that is a genuine reduction in exposure. It is also a control with an arithmetic ceiling, and understanding the arithmetic keeps you from mistaking a good program for a solved problem.

The attacker needs one success. If a plausible lure reaches 4,000 employees and a mature program has driven the credential-entry rate down to 1 in 500, the expected number of successful captures per campaign is eight. Drive it to 1 in 2,000 — an excellent, expensively maintained number — and you still expect two. Neither result is failure; both are non-zero, and non-zero times “attacker only needs one” is compromise on a schedule. Meanwhile the attacker adapts faster than the training cycle: lures now arrive as a reply inside a genuine thread from a supplier whose mailbox was already taken, timed to a real invoice, from a domain registered an hour ago.

There is a second, subtler ceiling. The behavior you are asking for — inspect the address bar before every credential entry — competes directly with the behavior the business rewards, which is dispatching work quickly. Under time pressure, on a phone, in a thread that looks like the eleven before it, human verification degrades. That is not a training deficiency; it is what human attention does. Controls that require sustained vigilance from a distracted person are controls with variance, and variance is what an attacker samples.

The arc from here is deliberate, and knowing it lets you read each module for its job. Module 2 lines up the four factors most organizations actually deploy — password, SMS OTP, TOTP, push — and shows that the handover test collapses them into one family, then states precisely what multi-factor authentication bought and what it did not. Module 3 introduces the adversary the rest of the course must defeat: a real-time reverse proxy that relays an entire login live, harvesting each factor as the victim supplies it and finishing with the session cookie. That module is the reason the course exists; every control before it loses to that attack.

Modules 4 and 5 remove the handover at the mechanism level. Module 4 replaces the shared secret with a key pair and walks the registration ceremony that mints it; Module 5 walks the login ceremony field by field. Module 6 is the heart: origin binding, the property that makes the Module 3 attack fail at exactly one comparison, demonstrated on the same wine-cellar login the attacker already beat once. Modules 7 and 8 refuse the victory lap — attestation and what it really proves, then the soft spots that survive, which is where competent attackers go next and where competent programs still lose.

One promise about tone. This course does not claim that hardware keys make accounts unhackable, and you should be suspicious of any material that does. It claims something narrower and more useful: that a specific attack, which defeats every other second factor in wide deployment, fails against this one for a reason you can point at in a byte string. Then it shows you where the attacker rationally goes instead.

A password is a shared secret: a value held identically by the user and (in some derived form) by the server, where possession of the value is the authentication. Everything else in this module is a variation on that theme, so it pays to be exact about why it fails.

The password's fatal property is that it is context-free. The string that authenticates you at cellar.example.com is the same string everywhere it is typed, and nothing in the act of typing it carries information about where it went. The user is the only component in the system with an opinion about the destination, and that opinion is formed by looking at a rendered address bar for a fraction of a second. There is no cryptographic relationship between the password and the site — the binding exists solely in the user's belief.

Storage improvements do not touch this. Hashing with a memory-hard function, salting, peppering, rate limiting — all of these harden the server-side corpus against offline attack, which is a genuinely important problem and a completely different one. A phished password was never in the corpus; it went straight from the user's fingers to the attacker's socket in plaintext. This is worth internalizing because it is the template for every mistake in this module: a control that protects a credential at rest or in bulk says nothing about a credential the user hands over voluntarily.

One-time codes address a specific weakness: the reusable password. If a value is good for only one login inside a 30-second window, then a value captured today is worthless tomorrow, and the entire breach-dump economy stops working against it. That is a real improvement and it explains the deployment.

TOTP derives a six-digit code from a shared seed and the current time, both sides computing independently. SMS OTP generates a code server-side and delivers it by text. Mechanically they differ in a way worth knowing — TOTP's seed never traverses a carrier network after enrollment, while SMS depends on a delivery channel that has been repeatedly compromised through SIM-swap and signalling attacks, which is why SMS deserves its lower reputation. But that distinction is about who else can obtain the code. Under the handover test the two are identical: the user reads a value off a screen and types it into a box, and the value works for whoever holds it.

The tempting objection is the clock. Thirty seconds is not much time; surely the attacker cannot act fast enough? This is the single most common reasoning error in the field, and it dissolves once you notice that the attacker is not acting after the fact. The attacker is present, live, holding a session with the real server open, waiting. The victim types the code into the attacker's page and the attacker forwards it in under a second. The validity window does not need to be defeated; it needs only to be occupied, and a real-time relay occupies it comfortably. Time-boxing raises tempo, not safety.

Push approval looks like it escapes the family, and its designers were solving a real problem: if there is no code, the user cannot type a code into the wrong box. That reasoning is correct and insufficient, because it addresses the transferred value while leaving the transferred approval untouched.

Consider what the user sees. A prompt appears on their phone saying that someone is signing in — perhaps with a city name and a browser string, both attacker-controllable to a useful degree. The prompt does not, and structurally cannot, show the user the origin of the browser session it will bless, because the prompt is generated by the identity provider in response to a login attempt, and every login attempt looks the same to the identity provider whether it originated from the victim's laptop or the attacker's server. The user is asked “is this you?” at a moment when they are, in fact, logging in. They say yes. The approval attaches to the attacker's session.

Two failure modes follow. The first is the timing attack just described: the attacker initiates a login at the instant the victim expects one, and the genuine expectation supplies the yes. The second is push fatigue — a prompt storm at 2 a.m. until someone taps approve to make it stop. Number matching, where the login screen displays two digits the user must enter into the prompt, was introduced to fix the second failure mode, and it does: you cannot answer a challenge you have not seen. It does nothing for the first, because an attacker relaying the login in real time can simply read the number off the page they are proxying and show it to the victim on their own lookalike screen.

Here is the master frame for the entire course. Three columns, each a yes/no question with a mechanical answer, applied to the four factors above plus the one this course is building toward.

Read the rows top to bottom and the ladder disappears. The first four differ in cost, convenience, and resistance to other attacks, and they resolve identically in all three columns. The last row flips all three, and it flips them because of a single design decision — the credential is a per-site key pair whose use is scoped to an origin — rather than because of three separate improvements. That is what “different in kind, not degree” means here, and it is why the rest of the course spends four modules on the last row.

Now the honest accounting, because a case that only lists MFA's failures is a case a competent skeptic will dismantle.

Before second factors were common, the dominant credential attack was bulk and asynchronous. Breach dumps were replayed at scale against unrelated services; a password stolen from a forum in 2013 opened a corporate mailbox in 2016. That attack is essentially dead against MFA-protected accounts, and its death is permanent, not a temporary lead. MFA also raised the operational cost of everything else: the attacker can no longer harvest credentials at leisure and use them at their convenience. They must be present, in real time, holding infrastructure, during the victim's actual login. That converts a batch job into a live operation with a narrow window, a per-target cost, and far more exposure to detection.

What MFA did not do is remove the handover. Every factor in the family is still something the user gives away, so the attacker's response was not to defeat MFA but to be there while it happens. This is the correct way to state the situation to an executive who has just funded an MFA rollout: the rollout worked, it eliminated an entire attack class, and the adversary responded by changing tactics in a way that the rollout does not address. Nothing was wasted. Something remains.

The attacker registers a domain chosen to survive a glance — a lookalike domain such as cellar-login.example-secure.com, which reads as reassuring and is entirely under their control — and obtains a valid TLS certificate for it in about ninety seconds from a free certificate authority. They point it at a reverse proxy configured with the real site's hostname.

What the proxy does is mechanically simple. An inbound request for /admin/login is rewritten and forwarded to https://cellar.example.com/admin/login; the response is streamed back with any absolute URLs pointing at the real host rewritten to point at the phishing host, so that the victim's next click stays inside the proxy. Nothing is cloned in advance and nothing goes stale. If the real site deploys a new login page at 3 a.m., the phishing site shows the new login page at 3 a.m. If the login flow has an unusual conditional step — a tenant selection screen, a consent prompt, a “your password expires in 4 days” interstitial — the proxy renders it correctly, because it is not simulating the flow but conducting it.

This defeats the entire family of user-facing tells that awareness training teaches. The page is not slightly wrong, because it is not a copy. There are no broken images, no outdated logo, no missing footer link. The connection is genuinely encrypted and the padlock is genuinely valid — the certificate correctly attests that you are securely connected to cellar-login.example-secure.com, which is a true statement about a host you should not be talking to. The only remaining tell is the domain name itself, read carefully, every time, by a person who has other work to do.

Now walk the login. The victim lands on the proxy and is shown the real login form. They type the admin password; the proxy records it and forwards it to cellar.example.com. The real server evaluates it, finds it correct, and responds with the TOTP prompt. The proxy passes the prompt through. The victim opens their authenticator app, reads 418 902, and types it in. The proxy records the code and forwards it — elapsed time from keystroke to arrival at the real server, a fraction of a second — and the real server validates it, because it is a genuinely valid code inside its window.

Notice what the real server experienced. It saw a login from an IP address (the proxy's) with a correct password and a correct, unexpired second factor. Every check it was designed to perform passed, and passed honestly. There is no anomaly at the protocol level, because there is no protocol anomaly: the credential material was real. Detection, if it happens, has to come from signals outside the authentication decision — an unfamiliar autonomous system, an impossible-travel calculation, a device fingerprint that does not match — all of which are probabilistic and all of which the attacker can degrade by proxying from a residential IP in the victim's city.

This is the moment to be precise about why Module 2's improvements do not help here. The password fell because it is reusable, but the code fell for a different-looking reason that turns out to be the same reason: the user handed over a value, and the attacker only needed it for the length of one relay. Time-boxing constrains when the value is useful, not to whom. Nothing in the ceremony asks the question that would matter — which site is this credential for? — because none of these factors has a way to represent the answer.

The credentials are not the objective. They are an inconvenience the attacker tolerates on the way to the thing that actually confers access.

When the real server finishes authenticating, it does what every web application does: it issues a session cookie — a bearer token representing “this browser has already authenticated as this user” — in a Set-Cookie header. That header travels back through the proxy, which reads it, stores it, and passes it on to the victim so the victim lands in a working, logged-in session and notices nothing. The attacker then loads the cookie into their own browser and is inside the account.

The consequences are worth stating individually because incident responders get them wrong under pressure. The second factor is now irrelevant. Authentication has concluded; the cookie is downstream of it. Prompting for MFA again would require the application to re-authenticate, which it has no reason to do for an established session. Rotating the password does nothing. The cookie was not derived from the password and does not become invalid when it changes — a fact that produces a very specific incident-review moment when the team discovers the attacker was still in the account four hours after the “containment” step. Only session revocation evicts them. Invalidating the server-side session, or rotating whatever key signs the tokens, is the action that matters, and it must be taken deliberately.

Step back from the specific sequence and the generality becomes visible. The proxy does not attack any factor. It attacks the channel, and it does so by occupying a position the factors have no way to notice.

Every credential in Module 2's family reduces, at authentication time, to a value or an approval that the user emits into a page. The proxy is the page. Whatever is emitted is captured and forwarded. The factor's individual improvements all operate on axes the relay is indifferent to: reusability (the relay only needs one use), validity window (the relay operates inside it), possession (the relay never touches the device), user awareness (the page is the real page). A factor could combine every one of these improvements and still lose, because none of them changes the fact that the user is handing something to whoever rendered the form.

That framing tells you what a solution must do, before you know what the solution is. It must either remove the emitted value — so that there is nothing worth capturing — or make the emitted value specific to the destination, so that a value produced for the proxy is useless at the real server. FIDO2 does both, which is why the last row of the taxonomy flips all three columns. Modules 4 and 5 build the first property; Module 6 builds the second, and the second is the one that actually kills this attack.

Challenge-response inverts the transaction. Instead of the user sending a secret that the server compares, the server sends a fresh random value — a nonce, or in WebAuthn's vocabulary a challenge — and the user's device returns a signature over it. The server verifies the signature against a public key it stored earlier. Possession of the private key is demonstrated; the private key is not transmitted, mentioned, or derivable from anything that was.

Two properties follow, and both are worth stating in the terms Module 2's taxonomy uses. First, nothing reusable crosses the wire. The signature is computed over a challenge that the server generated for this attempt and will not accept twice. An attacker who captures it in full holds a proof about a nonce that is already spent — the cryptographic equivalent of a receipt. Second, the emitted value cannot be produced without the key, so there is no path by which a user can be talked into generating the right signature elsewhere. They can be talked into signing, but what they sign is a specific challenge for a specific site, which is where Module 6 will pick this up.

Be precise about what this does and does not yet solve. Challenge-response alone defeats capture-and-replay. It does not, by itself, defeat a live relay — an attacker sitting in the middle could pass the real server's challenge to the victim, collect the signature, and forward it, exactly as they forwarded the TOTP code. Everything in this module is necessary and not yet sufficient. Hold that thought; it is the reason Module 6 exists and the reason this course does not treat “public-key authentication” as a synonym for “phishing-resistant.”

The private key is generated inside the authenticator and never exists anywhere else. This is not a policy or a configuration option; it is a property of the hardware. The secure element — a tamper-resistant chip in a USB key, or the equivalent secure enclave in a phone or laptop — generates the key pair internally, exposes the public half, and offers exactly one operation involving the private half: sign this input. There is no export command, because the command was never implemented.

Run the handover test against that. Clause one asks whether the user transfers a value or approval that the attacker can reuse. The user cannot transfer the private key even if they want to, even if a very convincing person on the telephone explains that the security team needs it. There is no user interface, no file, no string, no QR code that represents it. This is a categorical difference from every factor in Module 2, where the transfer was not merely possible but was the normal mode of use.

What the user can be induced to do is press the button — to authorize a signing operation. That is the remaining human-facing surface, and it is deliberately small: a signature over a challenge, for a site the browser names. Compare the surface areas. With a password, the human decision is “where do I type this reusable string,” with a wrong answer that is permanently costly. With a security key, the human decision is “do I touch this,” and the answer being wrong produces a signature that Module 6 will show is worthless to the attacker anyway.

Registration is where the credential comes into existence, and every property the course depends on is decided here. The ceremony runs between three parties: the server (the relying party), the browser, and the authenticator.

The server begins by generating a random challenge and sending it along with the relying-party identifier, information about the user account, and its preferences — which algorithms it accepts, whether it wants user verification, whether it wants attestation. The browser receives this, adds the true origin of the page it is on, and passes a request into the authenticator. The authenticator asks for a gesture — a touch, and possibly a PIN or biometric — and then generates a brand-new key pair, specific to this relying party and this user account. It returns the public key, a credential ID (the handle the server will use to ask for this specific key later), and a signature over the registration data. The private key stays inside.

Two aspects of that description are load-bearing. The key pair is new — nothing is reused across sites, so there is no cross-site correlation and no single credential whose compromise spans services. And it is bound to this relying party, recorded in the authenticator alongside the RP identifier, which is what lets the authenticator refuse to use it elsewhere. A security key holding credentials for forty sites holds forty independent key pairs, each of which will only ever be produced for the site it was minted for. That is the structural fact Module 6 turns into a phishing defense.

After registration, the wine-cellar server's credential table holds, per credential: a user handle, a credential ID, a public key, a signature counter, and some metadata about the authenticator. Consider what an attacker who exfiltrates that table can do with it.

They can verify signatures. That is the complete list. A public key is, by construction, a verification key — it lets you check that someone else produced a signature, and gives you no ability to produce one. The attacker cannot sign a challenge, cannot derive the private key, cannot use the credential ID for anything except naming a credential they cannot exercise. To be exact about the residual: the table is a list of which accounts exist and roughly what authenticators they use, which is a privacy matter and worth handling accordingly, but it is not an authentication matter.

Compare that to the password case, where a stolen hash table is a race. Good hashing makes the race long and expensive, but the attacker's work is offline, parallelizable, and permanently ongoing, and every weak password in the corpus falls eventually. This asymmetry has an operational consequence you can put in a risk register: a credential-table breach in a WebAuthn deployment does not require a mass password reset, does not require user notification on authentication grounds, and does not create a backlog of accounts at elevated risk. The incident is a privacy incident, sized accordingly.

Login begins on the server. It generates a fresh random challenge — 16 bytes or more of cryptographic randomness — records it against this login attempt, and sends it to the browser along with the relying-party identifier and, usually, the list of credential IDs registered for the account being signed into.

The challenge does one job and does it completely: it makes each assertion a statement about this attempt. The server accepts a signature only over the challenge it just issued, only once, and only within a short window. An assertion captured from yesterday's login, or from another session opened seconds ago, covers a different nonce and fails verification. This is the property that retires the entire replay class of attacks — the one that made backup codes and stolen passwords useful for months.

Two implementation details determine whether the property is real. The challenge must be server-generated and server-remembered: a challenge the client picks, or one the server recomputes from a timestamp, is not a nonce and can be anticipated. And it must be consumed — deleted or marked used when the assertion arrives — so that an assertion cannot be submitted twice. Both are easy to get wrong in a hurry, and both fail silently, since the happy path works perfectly either way.

The browser passes the challenge to the authenticator, which will not sign anything until a human does something. That requirement comes in two strengths, and confusing them is one of the more consequential mistakes in a deployment.

User presence (UP) means a human was physically there: a finger touched the key's contact, which cannot be satisfied by software. It proves someone is at the device. It does not prove who. User verification (UV) means the authenticator authenticated the human first — a PIN entered into the key, or a fingerprint or face match — before signing. It proves the person is the one who set the device up.

The difference is the difference between one factor and two. A security key that only requires a touch is something-you-have. A stolen key, in a stranger's hands, satisfies UP perfectly. A key that requires UV is something-you-have plus something-you-know-or-are, and the stolen key is inert without the PIN. Both flags are reported in the assertion, and the server can require what it needs — which means the server must actually check them, since an assertion produced with UP only is cryptographically just as valid as one produced with UV.

After the gesture, the authenticator signs and returns an assertion with three components. Knowing what is in each is what lets you reason about the next module rather than take its conclusion on faith.

clientDataJSON is assembled by the browser, not by the page and not by the authenticator. It contains the ceremony type (webauthn.get for authentication, webauthn.create for registration), the challenge echoed back, and the origin the browser is connected to. Hold that last one.

authenticatorData is assembled by the authenticator. It contains a hash of the relying-party identifier, a byte of flags including UP and UV, and the sign counter — a value the authenticator increments on each use.

The signature covers both: specifically, the authenticator signs the concatenation of authenticatorData and the SHA-256 hash of clientDataJSON. That construction is the quiet load-bearing detail of the entire course. Because the signature covers the hash of the client data, and the client data contains the origin, the origin is inside the signature. Nothing in the bundle can be altered — not the origin, not the challenge, not the flags — without invalidating it.

An assertion arrives. The server's job is not “check the signature” — that is one line of a checklist, and a deployment that stops there has thrown away most of the guarantee. The full acceptance test:

Two entries deserve comment. The sign counter is the most commonly dismissed check and the one whose purpose is most often misstated. It does not prevent cloning; it detects it. If two devices hold the same credential, their counters diverge, and a counter that goes backwards or fails to advance is evidence that something is wrong. Note the limits honestly: many authenticators — including most synced passkey implementations — report a constant zero, which is conformant and means the check simply does not apply. A server should treat a counter that moves as a signal it can use and a counter that is always zero as one it cannot, rather than rejecting the latter.

The origin row is the one the next module is about, and it is worth noticing now how ordinary it looks sitting in a checklist. It is a string comparison. That is the entire mechanism — and it is also, precisely because it looks like boilerplate, the check that gets loosened first when someone is debugging a staging environment at eleven at night and needs the login to work.

An origin is scheme, host, and port taken together — https://cellar.example.com — and it is the browser's fundamental unit of trust. Guide Nº 21 developed this at length: cookies, storage, and script access are all partitioned by origin, and the browser maintains that partition against a page that would very much like to escape it. The origin is not something a page asserts about itself; it is something the browser knows about the page, derived from the URL it actually fetched over the connection it actually opened.

When a page calls the WebAuthn API, it supplies several parameters — the challenge, the credential IDs to try, the user-verification preference. It does not supply the origin. The browser assembles clientDataJSON itself and writes in the origin from its own state, and there is no API surface through which script can influence that value. A page served from cellar-login.example-secure.com that calls the API will produce client data reading "origin": "https://cellar-login.example-secure.com", no matter what its JavaScript says, wants, or claims.

This is worth dwelling on because it is where the trust actually rests. The security of the whole scheme reduces to a claim about the browser: that it correctly reports the origin of the page invoking the API and cannot be talked out of it by that page. That claim is exactly the same one the entire web platform already depends on — if it were false, cookie scoping and the same-origin policy would fail first and far more loudly. The phishing defense is not a new trust assumption bolted onto the browser; it is a reuse of the one the browser was built to enforce.

Module 5 established the construction: the authenticator signs authenticatorData concatenated with sha256(clientDataJSON). Combine that with the previous section and the consequence is immediate. The origin is in the client data; the client data is hashed; the hash is signed. The origin is therefore covered by the signature, and any modification to it — by a proxy, a network device, a malicious script, anyone — changes the hash and invalidates the signature.

The semantic shift this produces is the heart of the matter. A password is a claim of the form “I know the secret.” A TOTP code is a claim of the form “I hold the seed, and it is currently 14:32.” Neither says anything about the recipient. A WebAuthn assertion is a claim of the form:

I am credential a7f3…, I was used by a present, verified human,
and I was produced for the site https://cellar.example.com.

That last clause is the difference in kind. The assertion is not a portable proof of identity that happens to be delivered somewhere; it is a proof about a destination, and delivering it elsewhere does not change what it says. An attacker who obtains it holds a signed statement that a user authenticated to the attacker's own site — which is true, and useless, because the real server was never the subject of the claim.

The mechanism only exists if the verifier uses it. Two related checks do the work, and they are not redundant.

The origin check compares the origin string in clientDataJSON against the relying party's expected origin — an allow-list the server holds as a constant. This is the phishing defense proper: it answers “was this assertion produced on a page served by us?”

The RP-ID check compares the rpIdHash in authenticatorData against the hash of the expected RP ID. The RP ID is a bare domain — cellar.example.com — rather than a full origin, and it is supplied by the authenticator from its own record of what the credential was registered for. This answers a different question: “is this the credential we minted for this relying party?”

Both exist because they are attested by different parties and can fail independently. The browser vouches for the origin (where the ceremony happened); the authenticator vouches for the RP ID (what the credential is for). The RP ID is also deliberately looser — it may be a registrable suffix of the origin's host, which is what lets one credential work across cellar.example.com and admin.cellar.example.com when the relying party wants that. That flexibility is useful and it is also why the RP-ID check alone is not the phishing defense: it is satisfied by any subdomain, while the origin check pins the exact host, scheme, and port.

Act three. The wine-cellar admin has enrolled a security key. The same attacker sends the same lure from the same domain, and the admin — who has had a busy week — clicks it again.

Everything proceeds as before, up to a point. The proxy fetches the real login page and renders it. The admin's browser is connected to https://cellar-login.example-secure.com. The real server generates a challenge; the proxy forwards it faithfully. Then the page — the real login page, conducted through the proxy — calls navigator.credentials.get(), and because it is the real site's own code it asks for the real site's credential: the call carries rpId: "cellar.example.com".

That is the request the browser will not honor. Before it invokes the authenticator — before any prompt appears, before the admin can touch the key or enter a PIN — the browser compares the requested rpId against the origin it is actually on. WebAuthn requires the rpId to equal, or be a registrable-domain suffix of, the caller's origin. cellar.example.com is neither equal to nor a suffix of cellar-login.example-secure.com, so the browser throws a SecurityError and stops. The authenticator is never asked. No gesture is collected, no client data is assembled, no signature is produced — there is nothing for the proxy to forward, because nothing was ever signed.

Notice what this does to the admin's role: she never gets the chance to do anything wrong. The relay does not fail because she scrutinised the domain or declined a prompt — it fails before a prompt could appear, on a comparison the browser makes on her behalf and without her cooperation. And the server's origin check, which the previous section built, is still there — it just never receives an assertion to judge, because none exists. It is the backstop: the line that would catch an origin-substituted assertion from a non-conforming client, a non-browser caller, or a bug, none of which the browser's own refusal covers. Defence in depth means the phish dies at the browser and, if the browser ever failed to hold, would die again at the server. Act three ends at the first of those two.

An attacker who has just watched that fail will look for a way around it, and it is worth walking their options, because the completeness of the failure is what distinguishes this from a control that merely raises cost.

Edit the origin in the assertion. Impossible: the signature covers the hash of the client data. Change one byte and verification fails at the signature check instead of the origin check — a different rejection, the same rejection.

Re-sign the modified assertion. Requires the private key, which is in a secure element with no export path and which the proxy has never touched. The proxy can relay bytes; it cannot produce a signature over bytes of its choosing.

Make the victim's browser report the real origin. Requires the victim's browser to be connected to cellar.example.com — at which point the victim is on the real site, there is no proxy in the path, and there is no attack. The browser reports the origin it has, and the attacker's whole position depends on that origin being theirs.

Ask the authenticator for a credential belonging to the real site. The authenticator will not produce it: the credential is registered against that relying party, and the browser will not offer credentials from an origin that does not match the RP ID. The refusal happens before any signing.

Line the requirements up and the structure becomes visible. To succeed, the attacker needs the victim's browser to be connected to the attacker (so the attack exists at all) and the signed origin to be the real server's (so verification passes). Those are the same variable with two required values. No cleverness closes a contradiction — which is why this is a guarantee rather than a mitigation, and why the honest attacker response is not to defeat the login but to go somewhere else entirely. That somewhere else is Module 8.

Separate two claims that everyday language runs together.

Claim A: “this assertion is valid.” Established by the verification in Module 5 — the signature checks out against the stored public key, the challenge and origin are right, the flags satisfy policy. What it proves: the private key paired with that public key was exercised, by a present (and possibly verified) human, for this site, on this attempt. This is a strong claim and it is sufficient for the phishing question.

Claim B: “a genuine hardware authenticator of a known make produced this.” Not established by any of the above. Verification is indifferent to where the key lives. A software authenticator, a virtual authenticator in a browser's testing tools, an emulated device in a research lab, or a certified token in a tamper-resistant package all produce assertions that verify identically, because verification only ever consults a public key.

The distinction matters wherever the control you are enforcing is about the device rather than the authentication. “Administrative access requires a hardware token that cannot export credentials” is a device claim. If your server accepts any credential that verifies, an admin can satisfy that control with a browser extension implementing WebAuthn in JavaScript, and every log entry will look correct. The control statement will be false and the evidence will look identical to the evidence for its truth.

Attestation is a registration-time statement, made by the authenticator and rooted in the manufacturer, saying in effect: this key pair was generated inside a device of this make and model, with these security properties. It is evidence about provenance, delivered alongside the new public key, and it is available only at registration — the moment the credential comes into existence.

The shape is a certificate chain, and if Guide Nº 19 is fresh you already know the pattern. The manufacturer holds a root key and certifies batches of devices; each device carries an attestation certificate that chains to that root; at registration the device signs a statement covering the new credential's public key and the challenge, and the relying party validates the chain against a set of trusted roots. The device also reports an AAGUID — an identifier for the model — and it is the attestation that makes the AAGUID mean anything, since an unattested device can report whatever AAGUID it likes.

Validating the chain requires knowing which roots to trust and what each model's properties are, which is what a metadata service provides: a signed catalogue of authenticator models, their attestation roots, their certification levels, and their known issues. Consuming one is the practical cost of requiring attestation — it is an external dependency you must keep current, and a stale catalogue rejects newly released models that are perfectly good.

One design note worth knowing: attestation certificates are deliberately shared across large batches of identical devices, typically at least 100,000. If each device had a unique attestation certificate it would be a global identifier for that device across every site it registered with. Batching keeps attestation a claim about a model rather than a tracking token for an individual — the deliberate resolution of a real tension between assurance and privacy.

Requiring attestation is not free. It adds an external metadata dependency, it rejects authenticators you have not blessed — including new models released after your catalogue was last updated — and in consumer contexts it collides badly with platform credentials, many of which provide no meaningful attestation at all. A consumer flow that requires attestation is a flow that tells a meaningful fraction of users their perfectly good phone is unacceptable, at the exact moment they are trying to enroll.

The decision turns on one question: is there a control that is a claim about the device?

Notice that attestation and phishing resistance are orthogonal. Every row of that table is equally phishing-resistant, because phishing resistance comes from origin binding and origin binding does not care what kind of device signed. Attestation answers a different question, and conflating the two produces both mistakes: teams that require attestation believing it is what stops phishing, and teams that skip it believing they have therefore weakened their phishing posture.

Everything this course has built is a property of a verifier that performs checks. Rushed implementations drop checks, and the dropped ones are predictable — they are the checks whose absence changes nothing about whether legitimate users can log in.

Rank them by what their absence costs. Skipping the origin check is catastrophic and silent: the deployment remains fully phishable, the AiTM proxy from Module 3 succeeds against it exactly as it did against TOTP, and nothing in the user experience or the logs distinguishes it from a correct implementation. Skipping challenge consumption restores replayability, so a captured assertion becomes a reusable credential — the property WebAuthn exists to remove. Skipping the UV flag check silently downgrades two factors to one for anyone whose key has no PIN. Skipping attestation costs the device claim only; the phishing resistance survives intact, which is why it sits at the bottom of this ranking despite being the module's subject.

The pattern is worth naming because it generalizes past WebAuthn: every check whose omission is invisible on the happy path will eventually be omitted by someone under deadline pressure. The countermeasure is not vigilance but adversarial tests that assert on specific rejection reasons — the ones Module 5's worksheet specified. A test that logs in successfully proves the feature works. Only a test that submits a bad assertion and asserts why it was rejected proves the guarantee exists.

People lose keys. They leave them in hotel rooms, snap them off in laptop ports, and hand them back with the laptop when they change jobs. Any deployment that does not plan for this will discover the plan under pressure, at which point someone will make an exception, and the exception will become the process.

The lazy path is to keep a weaker factor enrolled “just in case” — an SMS code or a TOTP app that still works if the key is unavailable. This is the phishable fallback, and its arithmetic is unforgiving. An account's phishing resistance is not the strength of its strongest factor; it is the strength of its weakest usable path. If the account can be entered with an SMS code, then the account can be phished, and the security key has become a preference rather than a control. Worse, it is a preference the attacker gets to override: a phishing page that says “security key unavailable? use your backup code” is a single line of HTML, and the victim who is running late will take the offer.

The correct answer is nearly always a second hardware key, enrolled at the same session as the first. Both are origin-bound, so the weakest usable path stays as strong as the strongest. One lives with the user and one lives in a safe, a desk drawer, or with the person who administers the account. The cost is real — a second piece of hardware per user and the logistics to distribute it — and it is smaller than the cost of any recovery process that has to authenticate a human by other means, which is the next section's subject.

Recovery is where an account is handed to someone who cannot currently authenticate. That is its purpose, and it means recovery flows necessarily authenticate a human by means other than the credential — an email link, knowledge-based questions, a document photo, or a conversation with a support agent. Every one of those is social, and social is the thing this course spent seven modules removing from the login.

So the attacker's move after the phish fails is not cryptographic. It is a phone call.

Read what failed. Not the cryptography — it was never consulted. Not the agent, who followed the process correctly and had no way to distinguish this call from the four legitimate ones that week. The process failed, in three specific ways: the verification questions tested knowledge that is obtainable rather than possession of anything; a single agent could complete a full authenticator reset on a privileged account without a second party; and urgency was allowed to compress the process, which is the lever every social engineer reaches for first. Notice also that the failed phishing attempt three weeks earlier was the reconnaissance for this one, and nobody connected them because the failed assertion was logged and never read — which is precisely the alerting gap Module 6's worksheet closed.

You will often authenticate on a laptop using a credential held on a phone. This is the hybrid transport — a QR code on the laptop screen, scanned by the phone, followed by a proximity-checked channel between them — and it deserves a careful assessment rather than either of the two easy verdicts.

The origin binding survives. The relying party's origin travels to the phone over the hybrid channel, the phone's authenticator signs over it, and the server checks it exactly as before. A proxy that renders a QR code on a phishing page does not get an assertion for the real site; it gets one for its own origin, and the story ends the way Module 6 ended. The design was built with this attack in mind.

What is added is a channel and its assumptions. The QR code carries a key that secures the phone-to-laptop channel, and the protocol requires a proximity check — a Bluetooth advertisement establishing that the two devices are physically near each other — specifically to stop an attacker from relaying a QR code to a remote victim. That check is the load-bearing addition, and it is where the honest caveats live: it depends on the platform implementing proximity correctly, and it is a newer, less battle-tested surface than the origin comparison that does the main work. Treat it as sound and as the newer part of the system.

The reasonable posture: hybrid is a legitimate, phishing-resistant flow and appropriate for most populations. For the highest-assurance accounts, prefer a directly attached authenticator, not because hybrid is known to be broken but because it has more moving parts, and for four admin accounts the cost of carrying a physical key is negligible. That is a defensible line to hold in a design review, and it avoids both the overclaim (“hybrid is just as good, always”) and the dismissal (“QR codes can be phished”), which is false as stated.

A synced passkey is a WebAuthn credential that a platform replicates across a user's devices through a cloud account. It is origin-bound and it is phishing-resistant — this must be said first and without hedging, because the most common error in this area is dismissing passkeys as a weaker thing. Against the attack this course is about, a synced passkey and a hardware key are equivalent.

They differ on a different axis: where the credential can exist and what secures that. A hardware key's private key exists in one chip and has no export path, so compromising the credential requires the physical object. A synced passkey's private key exists on every device in the sync fabric and, in encrypted form, in the provider's infrastructure — so its security is the security of the cloud account and the sync fabric's key management. That is usually strong, and it is a different and larger trust base than a chip in your pocket.

That last row is the practical judgment. For eleven thousand customers, a synced passkey is decisively the right answer: it is phishing-resistant, it survives a lost phone without a support call, and its adoption curve is the only one that gets a consumer population off passwords. For four admins with a device-provenance control, the hardware key is right. Both statements are true at once, and a program that picks one credential type for everyone is answering the wrong question.

The order of operations in a rollout determines whether it produces security or an outage.

Enroll before you remove. Every user gets their credentials — two hardware keys for privileged accounts, a passkey for consumer populations — and enrollment is confirmed by a real authentication before any weaker factor is disabled. Removing first produces a lockout event and a hastily approved exception process, which becomes the permanent recovery backdoor.

Harden recovery before you announce. The moment the login becomes unphishable, recovery becomes the cheapest path in. If recovery hardening lags the rollout, the program has moved the attacker rather than stopped them, and it has done so while telling everyone the problem is solved.

Make removal a dated, owned metric. “Percentage of privileged accounts with zero phishable factors enrolled” is the number that measures the program. “Percentage with a security key enrolled” measures the beginning of it and will happily read 100% while every account remains phishable.

Alert on the events that mean something. Origin mismatch (Module 6), factor enrollment on an existing account, and authenticator reset. All three are low-volume, high-signal, and all three are routinely logged and unrouted.

The catalogue, with the symptom and corrective for each: