CYBER-04-003-P · Primer — Multi-Factor Authentication: Something You Know, Have, and Are

The idea in one sentence

A password is one secret that anyone who steals it can reuse, so multi-factor authentication demands a second, independent proof — something you have or something you are — such that a thief who grabs your password still can't get in; but not all second factors are equal, and the phishing-resistant ones (FIDO2/WebAuthn) are in a different league from codes you can be tricked into typing or push prompts you can be nagged into approving.

Why it exists

Passwords fail in a way that's uniquely bad: they're a shared secret you have to hand over to prove you know it. Every time you log in, you transmit the thing that must stay private. That means it can be phished (you type it into a fake page), leaked in a breach of a totally different site, guessed, or reused across services. And here's the killer property — a stolen password works from anywhere, silently, with no sign to you that it happened. The attacker doesn't need your laptop or your face. They just need the string.

Multi-factor authentication (MFA) exists to break that single point of failure. The classic framing splits proofs into three factors: something you know (a password, a PIN), something you have (a phone, a hardware key, a smartcard), and something you are (a fingerprint, face, or other biometric). The whole point of MFA is to combine factors from different categories so that compromising one doesn't compromise the account. Steal my password (know) and you still lack my phone (have). The categories have to be independent — two passwords aren't MFA, and a password plus a "security question" isn't really MFA either, because both are just things you know that leaked in the same breach.

So MFA is the answer to a simple, brutal observation: passwords will be stolen, at scale, forever. Rather than pretend we can keep them secret, we make the stolen secret insufficient on its own.

How it works

MFA layers a second, different-category proof on top of the password. The interesting part is how that second proof is delivered, because the delivery mechanism decides how strong it actually is. Walk up the ladder from weakest to strongest.

SMS / email codes. The server texts you a one-time code; you type it back. This proves you (probably) control that phone number. It's the most common second factor and the weakest of the "have" options — SMS can be intercepted, and phone numbers can be stolen via SIM swapping (an attacker convinces the carrier to move your number to their SIM). NIST SP 800-63B specifically discourages SMS as a factor for exactly these reasons.

TOTP — time-based one-time passwords. An authenticator app (Google Authenticator, Authy, 1Password) and the server share a secret seed, set up once by scanning a QR code. Both sides then run the same algorithm (RFC 6238, built on the HMAC-based one-time password of RFC 4226): take the shared secret, take the current time chopped into 30-second windows, HMAC them together, and truncate to a 6-digit code. Because both sides compute independently from the same seed and clock, they agree on the code without ever transmitting the secret — a big improvement over SMS, since there's no code flying over a network to intercept. You just read it off your screen and type it.

Push MFA. Instead of typing a code, you get a notification on a registered app — "Approve sign-in?" — and tap yes. Convenient, and the secret never gets typed, so it can't be shoulder-surfed. But approval is a single tap, which sets up the fatigue attack described in the gotcha.

FIDO2 / WebAuthn — phishing-resistant. This is the leap. Instead of a shared secret or a code you type, your device (a hardware security key like a YubiKey, or a passkey stored in your phone or laptop) holds a private key and does public-key cryptography. Registration: the device generates a key pair and gives the public key to the site; the private key never leaves the device. Login: the site sends a random challenge, and the device signs it with the private key. The server verifies the signature with the stored public key. Two properties make this phishing-resistant. First, the private key is never transmitted or shown to you, so there's nothing for a fake page to capture. Second — and this is the magic — WebAuthn binds the signature to the real site's origin (the exact domain). If you land on paypa1.com instead of paypal.com, your authenticator simply produces the wrong signature (or refuses), because the origin doesn't match what it registered with. The user can't be tricked into signing for the wrong site, because the browser, not the human, checks the domain. Often a local gesture — a fingerprint or PIN (know/are) — unlocks the key on the device, giving you multiple factors in one tap.

The pattern across the ladder: the more the secret has to leave your control (texted, typed, tapped), the more ways it can be stolen or redirected. FIDO2 wins because the secret never leaves the device and the protocol checks the domain for you.

The one gotcha

Most MFA still asks a human to do the right thing under pressure — and humans can be phished or worn down. Only phishing-resistant factors move that decision out of the human's hands. Here's how the two dominant attacks exploit the gap. In real-time phishing (adversary-in-the-middle), the attacker runs a proxy page that looks like the real login. You enter your password and your TOTP code into the fake page; the proxy instantly relays both to the real site and captures the resulting session cookie. Your perfectly correct 6-digit code sailed straight to the attacker, because a code you can read and type is a code you can be tricked into typing somewhere else. In MFA fatigue (push bombing), the attacker already has your password and just hammers the "Approve sign-in?" button, sending you push after push at 2 a.m. until you tap "approve" to make it stop — or tap it by reflex. MITRE ATT&CK catalogs this as Multi-Factor Authentication Request Generation (T1621), and it's how several high-profile breaches began. The uncomfortable truth: SMS, TOTP, and basic push all still route the final decision through a person who can be deceived. FIDO2/WebAuthn defeats both attacks structurally — the domain-bound signature won't validate on the phishing proxy's origin, and there's no floating "approve" prompt to spam, because authentication requires physically touching your key on the real site. "We have MFA" is not the same as "we have phishing-resistant MFA." For high-value accounts, that difference is the whole ballgame.

See it — same password theft, three different endings

flowchart TD
    A["Attacker steals your<br/>password"] --> B{"What is the<br/>second factor?"}
    B -->|"SMS / TOTP code"| C["Phishing proxy relays<br/>the typed code -><br/>attacker gets in"]
    B -->|"Basic push approve"| D["Push bombing until<br/>you tap approve -><br/>attacker gets in"]
    B -->|"FIDO2 / WebAuthn"| E["Signature bound to<br/>real domain fails on<br/>fake site -> blocked"]
    C --> F["Account compromised"]
    D --> F
    E --> G["Attack stops at<br/>the password"]

The one-line takeaway

MFA works by demanding a second proof from a different category so a stolen password isn't enough — but the delivery method decides its strength, and only phishing-resistant factors (FIDO2/WebAuthn) survive real-time phishing and push fatigue by binding authentication to the real domain and your physical device.

Where you'll meet it

You'll meet this the first time a security team rolls out MFA and someone asks why SMS isn't good enough — or when an incident review traces a breach to an employee who approved one push prompt too many at midnight. You'll meet it when a compliance framework or cyber-insurance questionnaire distinguishes plain "MFA" from "phishing-resistant MFA," and suddenly TOTP everywhere isn't enough for the admin accounts. You'll meet it when you set up your first passkey and notice you never typed a code, and when a phishing simulation catches people entering real TOTP codes into a fake page. Interviewers probe it with questions that separate the layers: "what are the three authentication factors, and why must they be independent?", "how does FIDO2 resist phishing when TOTP doesn't?", "what is MFA fatigue and how would you defend against it?" The strong answer never treats all MFA as equal — it ranks the factors by how much the secret leaves the user's control, and names domain binding as the property that makes FIDO2 different.

Named concepts: authentication factors, TOTP & push MFA, phishing-resistant factors (FIDO2/WebAuthn), MFA fatigue & bypass