MFA / 2FA — The Best Single Defense Against Account Takeover

Server texts a 6-digit code; user types it. Better than nothing — and that's most of what should be said for it.

Weaknesses: SIM-swap attacks (attacker convinces the carrier to move the number to their SIM), SS7 routing flaws, and full phishability — the attacker's fake site can ask for the OTP and forward it. NIST has been deprecating SMS as a primary factor since 2017. Still acceptable as a fallback or for low-risk flows.

Time-based One-Time Password (RFC 6238). User scans a QR code; their authenticator app (Google Authenticator, Authy, 1Password, Bitwarden) generates a fresh 6-digit code every 30 seconds. The shared secret never leaves the device or server again.

Strengths: no SIM-swap risk, works offline, ubiquitous tooling.

Weaknesses: phishable (the attacker asks for the current code in real time), shared-secret-on-server means a server compromise leaks every secret.

The auth server pushes a "approve this login?" prompt to a paired app (Authy, Duo, Microsoft Authenticator). User taps approve. Smooth UX.

Weaknesses: "MFA fatigue" attacks — attacker spams approval prompts at 3 a.m. hoping the user taps to make them stop. Modern implementations show context (location, IP, app) and use number-matching ("type these two digits to approve") to defeat fatigue.

YubiKey, Google Titan, on-device platform authenticators (Touch ID, Face ID, Windows Hello). The browser asks the device for a signed assertion bound to the origin. The device only signs for the exact domain that registered it — phishing sites get nothing.

Why it's the gold standard: phishing-resistant by design. Even if the user gets fooled by a look-alike, the key won't sign for the wrong origin. NIST AAL3, FIDO2.

Backed by the same WebAuthn API that powers passkeys — see the passkeys deep dive.

Used as the local unlock for a stronger underlying factor. Touch ID doesn't transmit your fingerprint over the network — it unlocks a key stored in the secure enclave on your device. The factor is the device + key, gated by the biometric. Strong, when implemented this way.

Don't: send raw biometric templates to your server. They can't be rotated; a leak is permanent.

Generated at MFA enrollment, shown once, stored by the user. Single-use. Critical: without them, "I lost my phone" downgrades the user back to email-only verification — and email-only recovery is exactly the path attackers love.

WebAuthn / passkeys as primary, TOTP as fallback, SMS only if absolutely necessary. Let users register multiple factors so losing one doesn't lock them out.

The most common bypass: "I forgot MFA" → "we'll email you a reset link." The recovery flow becomes the weakest factor. Use printed backup codes; require multiple slow signals; notify the user via the old channel and quarantine sensitive actions for a cooldown.

Logging in once a week is one risk model; transferring $10,000 is another. Re-prompt for MFA — or step up to a stronger factor — at sensitive moments. This bounds damage even if a session token is later stolen.

Number-matching, contextual info (IP, location, app), aggressive rate-limiting on push prompts, automatic alerts after N rejected pushes. The goal: make a flood of pushes obvious to the user and ineffective for the attacker.

If you store the TOTP shared secret server-side, encrypt with a per-user envelope key from a KMS. A DB dump shouldn't reveal MFA secrets.

Auth0, Okta, Stytch, Clerk, Cognito, Firebase Auth, Twilio Verify. They handle factor enrollment, recovery, anti-fatigue, fraud signals. Building all of this in-house is rarely the right call.