Authentication Factors and MFA
Authentication is proving you are who you claim, and the strength of that proof is the difference between a stolen password mattering and not mattering. Factors come in three kinds — something you know, have, or are — and combining independent factors is the single most effective control against credential theft. But not all second factors are equal, and the difference decides whether MFA actually stops the intruder or just slows them down.
This topic goes past "turn on MFA" into which factors resist phishing and which only look like they do — a distinction that has become the whole game as attackers moved to real-time phishing proxies.
The Three Factor Types
A factor is knowledge (a password or PIN), possession (a phone or hardware key), or inherence (a fingerprint or face). Real multi-factor combines factors from different categories, so two passwords are not MFA — both are things you know, and one phish takes both. The point of a second factor is that stealing the password no longer suffices, because the attacker also needs something of a different kind.
The MFA Spectrum, Weakest to Strongest
Not all second factors resist the same attacks. SMS codes are phishable and vulnerable to SIM swapping. TOTP authenticator apps remove the SIM risk but a real-time phishing proxy still relays the six digits. Push approvals are convenient but vulnerable to fatigue, where an attacker spams prompts until the user taps approve. FIDO2 hardware keys and passkeys sit at the top: they are phishing-resistant by design.
Why WebAuthn and Passkeys Are Different
A FIDO2 credential is cryptographically bound to the site's origin and never leaves the device, so a look-alike phishing site simply cannot relay it — the browser will not release a credential registered for meridian.example to meridian-login.example. This is the one factor that structurally defeats phishing rather than merely discouraging it, which is why it is the target for anything that matters.
How MFA Actually Gets Bypassed
Attackers rarely break MFA; they route around it. Push-bombing spams approvals until someone taps yes. Real-time phishing proxies (adversary-in-the-middle) sit between the user and the real site, relaying the password and the TOTP code and then stealing the resulting session cookie — defeating every factor except an origin-bound one. And account-recovery flows that skip MFA are the classic back door: why phish the login when "forgot password" resets it?
SMS — better than nothing, but SIM-swap and interception make it the weakest; avoid it for high-value accounts.
TOTP — no SIM risk, but a real-time phishing proxy relays the six digits.
Push — convenient, but fatigue and bombing work unless number-matching is on.
FIDO2 / passkey — origin-bound and phishing-resistant; the target for admins, production, and anything that matters.
- Treating SMS MFA as strong and using it for admin accounts, when SIM-swap and interception defeat it.
- Leaving account-recovery flows outside MFA, so "forgot password" becomes the MFA bypass.
- Enabling push approvals without number-matching, opening the door to push-fatigue attacks.
- Assuming any MFA equals phishing-resistant MFA, when only origin-bound factors stop a real-time phishing proxy.
- Counting two knowledge factors (password plus security questions) as MFA, when both are things you know and one phish takes both.
- Require phishing-resistant MFA (FIDO2 or passkeys) for administrators, production, and anything high-value, and make it the default rather than an option.
- Kill SMS as a factor for privileged accounts and enable number-matching on any push-based flow.
- Bring account recovery under the same MFA bar as login, so recovery is not the soft underbelly.
- Monitor for MFA anomalies — repeated denials, impossible travel — and treat push-bombing as an active attack signal.
- Move toward passwordless where you can, so there is no password to phish in the first place.
Knowledge Check
Why do FIDO2 security keys resist phishing when TOTP codes do not?
- The credential is bound to the site's origin
- They generate much longer numeric codes that are far harder to mistype
- They expire after a few seconds, unlike TOTP
- They are stored on the server rather than the device
An organization has MFA on login but not on account recovery. Why is this dangerous?
- The weaker "forgot password" flow bypasses strong login entirely
- Recovery flows are always slower, which needlessly frustrates legitimate users
- MFA on login stops working once recovery is enabled
- It doubles the cost of every authentication
Why are a password plus three security questions not real multi-factor authentication?
- Both are things you know
- Security questions are stored encrypted on the server while passwords are not
- Three questions is too many for users to remember
- Security questions count as a possession factor
You got correct