Multi-factor authentication: TOTP and WebAuthn

A password alone is one factor — something an attacker can phish, guess, or buy off a breach dump for a few dollars. MFA adds a second, independent factor, but not all second factors are equal, and the most common one (SMS) is now the weakest choice available.

Beginner

3 min read

Why one factor isn't enough

A password is "something you know." The problem is that "something you know" is trivially copyable — it can be phished, reused from another breach, guessed, or simply typed into a fake login page that looks identical to the real one. None of those attacks require touching your device.

Multi-factor authentication (MFA) requires a second, independent factor before login succeeds — typically "something you have" (a phone, a hardware key) or "something you are" (a fingerprint). The point isn't redundancy for its own sake: it's that stealing a password no longer gets an attacker in, because they'd also need to steal your phone or your fingerprint.

TOTP: a shared secret and a clock

Time-based One-Time Password (TOTP) is what most authenticator apps (Google Authenticator, Authy, 1Password) implement. At setup, the server generates a random secret and shares it with your app, usually via a QR code. From then on, both sides independently compute the same 6-digit code every 30 seconds, using the shared secret and the current time as inputs:

code = HOTP(secret, floor(current_unix_time / 30))

No network round-trip is needed to generate or verify a code — both sides just need the same secret and roughly synchronized clocks. This is TOTP's main strength (it works offline) and its main weakness (the secret is a shared value that has to be stored on the server; if your server's secret store leaks, every user's codes are computable).

WebAuthn and passkeys: proof of possession without a shared secret

WebAuthn takes a different approach: public-key cryptography instead of a shared secret. At registration, your device (a phone, a hardware key like a YubiKey) generates a key pair and gives the server only the public key. To log in, the server sends a random challenge; your device signs it with the private key, which never leaves the device:

Because there's no shared secret, there's nothing on the server worth stealing to impersonate a user, and because the signature is bound to the origin (the domain requesting it), a phishing site that isn't the real domain simply can't get a valid signature — WebAuthn is phishing-resistant in a way TOTP isn't. Passkeys are WebAuthn credentials designed to also work as a full password replacement, often synced across a user's devices via their platform (iCloud Keychain, Google Password Manager).

Why SMS-based MFA is now considered weak

SMS was the first mainstream "second factor," and it's still common, but it has two structural problems that have nothing to do with implementation quality: SIM-swapping (an attacker socially engineers your carrier into porting your number to their SIM) and SS7 network interception (the telecom signaling protocol has known weaknesses that let sophisticated attackers intercept texts in transit). Neither requires compromising your phone. NIST's digital identity guidelines have formally discouraged SMS as an authentication factor for exactly this reason — it's better than nothing, but it's the floor, not a good default.

Enforcing MFA without locking users out

Requiring MFA raises a real operational question: what happens when someone loses their phone? The standard answer is backup codes — a batch of single-use codes generated at enrollment, shown once, and stored by the user somewhere offline. Don't email recovery codes on demand (that turns a compromised inbox into an MFA bypass) and rate-limit MFA attempts the same way you'd rate-limit password attempts, since a 6-digit TOTP code is guessable given enough tries without a lockout.