Passwords are a problem of probability. A password is usually guessed, phished, or leaked once — and then the whole account is gone. Two-factor authentication answers differently: it raises the number of independent things an attacker must hold simultaneously. This is the single most effective account-security upgrade available, for users and developers alike.
What "factor" actually means#
A factor is one of three independent categories:
- Something you know — the password or PIN
- Something you have — your phone, a security key
- Something you are — biometrics (face, fingerprint)
Two-factor means two of these different categories. A second password is not 2FA; a fingerprint plus a password is. The whole point is that losing one factor should not compromise the account.
"Something you have" is so strong precisely because it is not you. A phisher who steals your password still lacks your physical device.
The factor hierarchy#
Not all "have" factors are equal. Ranked by resistance to remote attack:
| Method | What it is | Weakness |
|---|---|---|
| TOTP app (Google Authenticator, Authy, 1Password) | Time-based one-time codes generated on your device | Seed stored at setup; phishing can trick you into entering a code |
| SMS | Code sent by text to your number | SIM-swap attacks redirect the code; telecom-level interception |
| Push approval | Prompt on a trusted device | Usually fine; some phone-unlock bypass exists |
| Security key / passkey | FIDO2/USB key, or platform passkey | Nearly none — cryptographically bound to the site origin |
Modern guidance is shifting hard toward passkeys (FIDO2), which replace the password entirely — possession plus biometric becomes the primary authentication, not a second step. Meanwhile, TOTP remains the strongest widely-available option for most people today.
Why SMS is the weakest "have"#
SMS 2FA is still far better than none: it stops casual password reuse and credential-stuffing. But it is the only architecture where the code travels through someone else's channel. If an attacker convinces a carrier to move your number (SIM swap), the second factor arrives in their hands. For anything high-value — email that can reset everything, banking, crypto — use an authenticator app or security key instead.
Practical setup checklist (individual)#
- Enable 2FA on your email first — it is the password-reset hub for everything else.
- Prefer an authenticator app (TOTP) over SMS for high-value services.
- Back up your recovery codes offline (printed, or in a password manager). Losing 2FA without recovery = locked out permanently.
- Use a password manager that stores TOTP seeds if you already trust it (1Password, Bitwarden) — it makes 2FA more likely to be used.
- Add a physical security key for the single most important account (your Google/Apple/iCloud account) if you can.
- Turn on 2FA for: email, bank/fintech, crypto, password manager, dev accounts (GitHub/GitLab), cloud consoles.
The trap most people hit: they turn on 2FA, then phone dies, and recovery codes were never saved. Setup is not finished until recovery is tested.
What phishing does to TOTP#
A code that changes every 30 seconds is still phishable. A lookalike login page can harvest "username + password + live TOTP code" in real time and replay it. This is the entire reason phishing-resistant factors (security keys/passkeys) exist — they bind the credential to the site's origin, so the code taken from evil-login.example is useless at real-login.example.
Think of it as a factoring rule: TOTP stops guessing, SMS stops guessing plus simple attacks, passkeys stop guessing and phishing.
For developers: shipping 2FA responsibly#
If you add 2FA to a service, the happy path is not the hard part — the recovery path is.
- Backup options: recovery codes or a secondary device. Never offer "we can't help if you're locked out" as a silent default; decide explicitly whether support can intervene.
- Session fixation: after 2FA succeeds, rotate the session ID and consider forcing re-login of old sessions.
- Rate-limit the verification step separately from login — the TOTP submit endpoint is a brute-force target.
- Never log the code. TOTP seeds and codes must never appear in logs; one logging mistake breaks the secrecy of the whole second factor.
- Passkeys first: public-key architecture means no server-side secrets to leak. WebAuthn registration returns a public key; the private key never leaves the device.
Many breaches of 2FA implementations happen not in the crypto but in the recovery flow — an attacker resets "recovery" through support chat with only a few identity questions.
The practical end state#
| Who types what | |
|---|---|
| No 2FA | password only |
| 2FA (TOTP) | password + 6-digit code (or FIDO) |
| Passkey | biometric (face/fingerprint) locally |
Session theft doesn't stop at login, but 2FA materially raises the bar: stolen passwords stop being enough. Combine it with good password hygiene (password managers done right) and phishing awareness (anatomy of a phishing attack), and the realistic attacker cost rises sharply for almost no daily friction.
