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.
- 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.
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.
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-1combines 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.
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.
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.
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.
References
- IETF, RFC 4226: HOTP, An HMAC-Based One-Time Password Algorithm, 2005.
- IETF, RFC 6238: TOTP, Time-Based One-Time Password Algorithm, 2011.
- W3C, Web Authentication (WebAuthn), Level 2, Recommendation.
- FIDO Alliance, FIDO2: WebAuthn and CTAP.
- CISA, Implementing Phishing-Resistant MFA, fact sheet.
- NIST, SP 800-63B: Digital Identity Guidelines, Authentication and Lifecycle Management.
- Microsoft Security, From cookie theft to BEC: AiTM phishing sites, 2022.
- OWASP, Multifactor Authentication Cheat Sheet.
- ANSSI, Recommendations on multifactor authentication and passwords (French).