MFA explained: why not all second factors are equal

Multi-factor authentication requires evidence from more than one category before granting access. The categories are conventionally: something you know (a password), something you have (a device or key), and something you are (a biometric).

Two passwords are not MFA. A password and a security question are not MFA — both are things you know, and both can be obtained the same way. The point of using different categories is that compromising one does not compromise the other.

The methods, from weakest to strongest

SMS one-time codes

Better than nothing, and the weakest option in common use. Three separate problems: SIM swap, where an attacker persuades the carrier to move the number to their own SIM; SS7 interception, exploiting the signalling protocols between carriers; and ordinary phishing, since the code is just a string the user can be persuaded to read out.

NIST removed SMS from its recommended methods for new systems years ago. It remains widespread because it requires nothing of the user.

Authenticator apps (TOTP)

A shared secret and the current time produce a six-digit code every thirty seconds. This removes the carrier from the picture entirely — no SIM swap, no SS7. It remains phishable, because the user can type the code into a fake site as easily as a real one.

Push notifications

Convenient, and vulnerable to a behavioural attack that SMS and TOTP are not: MFA fatigue. An attacker with the password simply requests approval repeatedly until the user accepts one to stop the notifications. This was the mechanism in several widely reported 2022 breaches.

Number matching largely fixes it — the screen displays a number the user must type into the app, so approval cannot be given reflexively. If you use push, enable number matching.

FIDO2, WebAuthn, passkeys and hardware keys

The only phishing-resistant option, and the reason is structural rather than educational. The credential is a key pair bound to the site's origin. The browser will not release a credential registered for example.com to examp1e.com — not as a warning the user can dismiss, but as a refusal the user cannot override.

This defeats the attack that beats every other method: the attacker-in-the-middle proxy. A proxy relaying the real login page captures passwords and one-time codes perfectly well, and gets nothing from a hardware key, because there is no code to relay.

The attack that beats everything except FIDO2

Tooling such as Evilginx proxies the genuine site rather than imitating it. The victim sees the real page — because it is the real page — enters their password and their code, and both are forwarded to the real service. The attacker captures the resulting session cookie, which represents an already-authenticated session and has already satisfied the second factor.

SMS, TOTP and push all fall to this equally. It is the single strongest argument for hardware-backed credentials on accounts that matter.

Practical guidance

• Administrators and anyone who can move money: FIDO2, mandatory. No exceptions and no fallback to a weaker method, because a fallback is what an attacker will invoke.
• Everyone else: authenticator app or passkey. SMS only where nothing else is possible.
• Enable number matching if push is in use.
• Issue two hardware keys per person. One lost key should not mean an account recovery process, because that process is the weakest link in the whole design.
• Shorten session lifetimes on sensitive applications. MFA protects the login, not the session that follows it.
• Re-prompt on sensitive actions — changing bank details, adding a mail rule, granting OAuth consent — not only at sign-in.

The part people forget

Account recovery is authentication too, and it is usually far weaker than the front door. If a help desk can reset MFA on a phone call, the strength of your MFA is the strength of that phone call. Recovery paths deserve at least as much scrutiny as the login itself.