Skip to main content
Xsec

Multifactor Authentication

Published on 7 min read

Updated on

Multifactor authentication (MFA) requires at least two pieces of evidence from different families before it grants access. That last word matters: two passwords are not MFA, but a password plus a hardware key is. The goal is not to make login harder, it is to ensure that compromising one factor, a leaked password, a stolen phone, does not compromise the account.

Multifactor authentication is the single highest-leverage setting most people never turn on. This article explains what a factor actually is, how the common methods are computed at the protocol level, why one-time codes are now routinely bypassed, and which form of MFA still resists the phishing kits that defeat the rest.

The three factor families

Authentication factors fall into three families, and MFA means drawing from more than one of them.

Technical diagram
WHAT COUNTS AS A FACTOR: Real MFA combines factors from different families, so one stolen factor is never enough.MFA · THE THREE FACTOR FAMILIESWHAT COUNTS AS A FACTORReal MFA combines factors from different families, so one stolen factor is never enough.FAMILIES OF PROOFEXPOSURE OF THAT FAMILY ALONEexposed toSOMETHING YOU KNOWKnowledgepassword, PIN, questionSOMETHING YOU HAVEPossessionphone, OTP app, FIDO2 keySOMETHING YOU AREInherencefingerprint, face, irisWEAKNESSPhishable, reusedbrute force, credential stuffingWEAKNESSRelayed or lostSIM swap, device theftWEAKNESSCannot be revokeda leaked biometric is foreverKNOWLEDGE · POSSESSION · INHERENCE · TWO DIFFERENT FAMILIES · NEVER TWO OF THE SAME
The three authentication factor families and the weakness each one carries alone.How to read the diagramEach column is one family of proof. Strength comes from combining factors of two different families: an attacker who phishes a password (left) still lacks the possession or inherence factor beneath it. Two factors from the same family, such as a password and a security question, are not MFA.
  • Knowledge factors, something you know: a password or PIN. Familiar, but weak alone. They are exposed to brute force, credential stuffing with passwords leaked from other breaches, phishing, keylogging, and interception.
  • Possession factors, something you have: a phone, an authenticator app, or a security key such as a YubiKey. An attacker now needs your credentials and your device. Keys built on the FIDO2 standard are the strongest possession factor available, and they change the game entirely, as we will see.
  • Inherence factors, something you are: fingerprint, face, or iris. Hard to forge, but with a permanent trade-off: unlike a password, a compromised biometric cannot be reissued.

The security gain is compositional. Even if one factor is broken, the attacker still lacks the others, which is what blunts brute force and ordinary phishing. The failure mode to remember is combining two factors from the same family (a password and a security question are both knowledge), which adds friction without adding independence.

DangerStrong passwords, but what about cookies?

Everyone talks about strong passwords and password managers, but MFA does not protect an already-established session. An attacker who steals your session cookies inherits an active, authenticated session, bypassing both the password and the second factor no matter which method you used. This is the gap the last two sections of this article are about.

One-time passwords: TOTP and HOTP

The most common second factor is the six-digit code from an authenticator app. Two closely related algorithms produce it, and both are just an HMAC over a shared secret and a counter.

Technical diagram
HOW A ONE-TIME CODE IS COMPUTED: A shared secret and a moving counter feed an HMAC that is truncated to the digits you type.OTP · TOTP AND HOTP (RFC 6238 / RFC 4226)HOW A ONE-TIME CODE IS COMPUTEDA shared secret and a moving counter feed an HMAC that is truncated to the digits you type.GENERATING THE CODETOTP VS HOTPflavorsENROLLShared secretQR, both sidesCOUNTERMoving valuetime step or eventMIXHMAC-SHA-1secret + counterTRUNCATETruncation31-bit, mod 10^6DISPLAYSix digitstyped by userTIME-BASEDTOTPexpires in ~30s, RFC 6238EVENT-BASEDHOTPvalid until used, RFC 4226VALIDATIONSkew windowserver allows a step or twoSHARED SECRET · MOVING COUNTER · HMAC-SHA-1 · DYNAMIC TRUNCATION · SIX DIGITS · SKEW WINDOW
Simplified HOTP and TOTP generation, the math behind authenticator-app codes.How to read the diagramAt enrollment, client and server store the same secret (the QR code). A counter, elapsed time in 30-second steps for TOTP or an incrementing event for HOTP, is combined with the secret through HMAC-SHA-1. Dynamic truncation reduces the digest to a 31-bit number, taken modulo one million to yield six digits. The server recomputes the same value and accepts a small window of clock skew.

Time-Based One-Time Password (TOTP), standardized in RFC 6238, uses the current time as the source of uniqueness:

  • a shared secret is established at enrollment, the QR code you scan;
  • the current time divided by a step (typically 30 seconds) becomes the counter;
  • HMAC-SHA-1 combines that counter with the secret;
  • the digest is reduced by dynamic truncation to a 31-bit number, taken modulo one million to give the six digits.

Because the counter advances with the clock, a TOTP code expires after 30 to 60 seconds. HMAC-Based One-Time Password (HOTP), RFC 4226, is the same construction with an event counter that increments on each use instead of on the clock. The trade-off is directly visible in the diagram: HOTP codes do not expire until used, which is convenient but widens the window an attacker can exploit. In both cases the server recomputes the expected value and accepts a small skew window so a slightly fast or slow clock still validates.

Push notifications

Many services skip the typed code and send a push notification to a trusted device: you approve or deny the login. Push has become one of the most common second factors because it is more usable than a typed code: you approve instead of transcribing digits. But as the bypass section shows, an approval a human can grant is an approval an attacker can solicit.

Phishing-resistant MFA: FIDO2 and WebAuthn

Every method above shares one weakness: it produces something the user hands over, a code or an approval, that an attacker positioned in the middle can relay. FIDO2, the combination of the W3C WebAuthn browser API and the FIDO Alliance Client to Authenticator Protocol (CTAP), removes that something entirely by replacing shared secrets with public-key cryptography.

Technical diagram
PHISHING-RESISTANT AUTHENTICATION: The device signs a server challenge scoped to the real origin; nothing reusable is ever sent.FIDO2 · WEBAUTHN CHALLENGE-RESPONSEPHISHING-RESISTANT AUTHENTICATIONThe device signs a server challenge scoped to the real origin; nothing reusable is ever sent.AUTHENTICATION FLOWWHY PHISHING FAILSresistsSERVERSends challengerandom nonceBROWSERAdds real originthe domain in the barAUTHENTICATORSigns itprivate key stays putASSERTIONSigned responseorigin + counterSERVERVerifiesstored public keyORIGIN-BOUNDDomain in the signaturea fake site cannot matchNO SECRETNothing to stealkey never transmittedNO CODENothing to relaythe user types no OTPRANDOM CHALLENGE · ORIGIN BOUND · PRIVATE KEY ON DEVICE · SIGNED ASSERTION · PUBLIC-KEY VERIFY
WebAuthn authentication (FIDO2). The private key never leaves the authenticator.How to read the diagramThe server sends a random challenge. The browser attaches the real origin it is talking to, then the authenticator signs both with a private key that never leaves the device. The server checks the signature against the public key stored at registration. Because the signature is bound to the origin and there is no shared secret to type, a look-alike phishing domain cannot obtain a usable response.

At registration the authenticator (a security key, or the secure element in a phone or laptop) generates a key pair, keeps the private key on the device, and gives the server the public key. At login the server sends a random challenge; the browser attaches the origin, the exact domain in the address bar; and the authenticator signs the pair. The server verifies the signature with the stored public key.

Two properties make this phishing-resistant, the term the US CISA fact sheet on implementing phishing-resistant MFA uses for the gold standard. The signature is bound to the origin, so a look-alike domain receives a signature that will not verify for the real site. And there is no shared secret and no code to type, so there is nothing for a victim to reveal or an attacker to replay. This is why CISA names only FIDO/WebAuthn and PKI (smartcards) as phishing-resistant, and why passkeys, which are FIDO2 credentials synced across your devices, are the consumer face of the same technology.

How MFA gets bypassed anyway

MFA is not magic, and knowing how it fails tells you which method to choose. The dominant technique today is adversary-in-the-middle (AiTM) phishing.

Technical diagram
WHY MFA ALONE IS NOT ENOUGH: A reverse-proxy phishing kit relays the code you type and steals the session cookie behind it.MFA BYPASS · ADVERSARY-IN-THE-MIDDLEWHY MFA ALONE IS NOT ENOUGHA reverse-proxy phishing kit relays the code you type and steals the session cookie behind it.THE RELAY ATTACKWHAT ACTUALLY STOPS ITdefended byVICTIMClicks the linklook-alike loginPROXYRelays liveEvilginx-styleSECOND FACTOROTP or pushrelayed onwardREAL SITEIssues cookieMFA satisfiedATTACKERSteals cookiereplays the sessionPHISHING-RESISTANTWebAuthn origin checkthe proxy origin failsBINDINGToken tied to devicea stolen cookie is uselessCONTEXTAdaptive re-authnew IP or new deviceRELAYED CREDENTIALS · RELAYED OTP · STOLEN SESSION COOKIE · REPLAYED WITHOUT MFA · WEBAUTHN BREAKS IT
AiTM phishing (Evilginx-style). The stolen session cookie replays with no MFA prompt.How to read the diagramThe victim logs in on a proxy that relays every field to the real site in real time, including the OTP or push approval. The real site, seeing valid credentials and a valid second factor, issues a session cookie. The proxy captures that cookie; replaying it grants access with no further MFA. TOTP, HOTP, SMS, and push are all relayable this way, which is why origin-bound WebAuthn is the control that breaks the relay.

Instead of a static fake page, an AiTM kit such as Evilginx runs a reverse proxy between the victim and the real site, relaying every field live. The victim enters their password, then their OTP or approves the push; the proxy forwards each to the genuine service, which is satisfied and issues a session cookie. The proxy captures that cookie, and the attacker replays it in their own browser: they are now inside the account with no further prompt, exactly the cookie-theft gap flagged earlier. Microsoft documented this pattern moving from AiTM cookie theft straight into business email compromise. Because the code is relayed rather than cracked, TOTP, HOTP, SMS, and push are all vulnerable.

The other classic techniques share the same root, a factor the user can be induced to surrender:

  • MFA fatigue (“prompt bombing”): flood the user with push requests until one is approved out of exhaustion.
  • Man-in-the-middle: the general case AiTM specializes, capturing and replaying credentials or tokens.
  • Social engineering: talk the user into revealing a code or approving a request.
  • SIM swapping: hijack the phone number to intercept SMS codes (a reason to prefer app-based or hardware factors over SMS).
  • Infrastructure attacks: steal signing keys or exploit weaknesses in the identity provider itself.
ImportantWhat actually stops the relay

Notice which controls sit in the lower band of the bypass diagram. Origin-bound WebAuthn breaks AiTM because the signature never matches the proxy’s domain. Binding the session token to the device makes a stolen cookie useless elsewhere. And adaptive context (a new IP or device forcing re-authentication) narrows the window. Of these, phishing-resistant MFA is the only one that stops the attack rather than shrinking it.

Adaptive MFA

Enterprise deployments add adaptive (risk-based) authentication: contextual signals such as location, time of day, IP reputation, and device posture decide which factors to demand. A login from a known home device might pass on password alone, while the same account from a new country triggers a step-up challenge. Adaptive policy does not replace a strong second factor; it decides when to insist on one, and it is the mechanism behind the “new IP or device” control above.

Choosing, in one line

Turn MFA on everywhere. Prefer an authenticator app or a hardware key over SMS. And for anything that matters, a bank, an email account, an identity provider, use a FIDO2 security key or passkey: it is the only widely available method that survives the phishing kit in the last diagram.

For a concrete consumer-account walkthrough, Reducing Your Attack Surface on Discord combines MFA with email compartmentalization, application permissions, and messaging settings.

SummaryThe model in one line

MFA works by demanding proof from independent families, so one compromise is not enough. One-time codes deliver that independence but can be relayed by an attacker in the middle; FIDO2 and WebAuthn bind the proof to the real domain and to your device, which is what actually defeats modern phishing.

References

Use with an AI

Actions