Why is SMS or TOTP-based MFA considered weaker than passkeys, and what makes an authentication factor phishing-resistant?

technical-conceptual · Mid level · cloud-devops-security

What the interviewer is really asking

Test current authentication knowledge — understanding that shared-secret MFA is phishable via adversary-in-the-middle, and what property of FIDO2/WebAuthn (origin binding, key never leaving the device) actually defeats phishing.

What to say

• Explain the weakness concretely: SMS and TOTP both rely on a shared one-time code the user reads and types, so they're phishable — an adversary-in-the-middle proxy (Evilginx-style) relays the login page, captures the code in real time, and replays it to hijack the session; SMS adds SIM-swap and SS7 interception on top.
• Define phishing-resistance precisely: the factor must be bound to the legitimate origin and never produce a credential a human can be tricked into handing over. FIDO2/WebAuthn passkeys achieve this — the authenticator signs a challenge with a private key that never leaves the device, and the signature is scoped to the real domain, so a look-alike phishing site gets nothing the attacker can use.
• Show pragmatic judgment: passkeys are the gold standard and what NIST/regulators now push for high-value access, but adoption is gradual — so a sensible posture is passkeys for admin/privileged and high-risk flows, TOTP as a far better fallback than SMS, and SMS only as a last resort, while phasing it out.

What to avoid

• Calling TOTP or SMS 'secure enough' MFA without acknowledging real-time AitM phishing defeats both.
• Treating SMS and authenticator-app TOTP as equivalent — SMS is additionally exposed to SIM-swap and SS7, making it the weakest common factor.
• Saying any MFA is fine because 'it's still two factors' — phishing-resistance is a distinct property that most MFA lacks.

Example answers

Strong: After a phishing campaign captured an engineer's TOTP through an AitM proxy and got a short-lived session, we moved all admin and production access to WebAuthn passkeys on hardware keys. Because the passkey signs a challenge bound to our real domain and the private key never leaves the key, the same proxy attack now fails — the look-alike origin can't get a usable signature. We kept TOTP as the fallback for low-risk apps and killed SMS as a factor entirely.

Weak: SMS codes are fine for MFA because the attacker would also need the user's password, and two factors is enough.