The idea behind two-factor authentication is simple: require a second proof of identity beyond a password. Even if an attacker steals your password, they can't log in without the second factor. In practice, the security you get depends almost entirely on which second factor you use — and the gap between the best and worst options is significant.
This piece walks through four common approaches: SMS-based codes, time-based one-time passwords (TOTP), hardware security keys, and passkeys. For each, we'll cover how it works technically, what attacks it resists, and where it fails.
SMS One-Time Codes
When a service texts you a six-digit code at login, it's using SMS as a second factor. The code is generated server-side, delivered over the cellular network, and you type it into the login form. This is the most widely deployed form of 2FA.
It is also the most fragile. SMS has three significant attack vectors that don't require compromising your device:
- SIM swapping — An attacker calls your carrier, impersonates you, and convinces them to transfer your number to a SIM the attacker controls. SMS codes then route to the attacker. This attack has been used against cryptocurrency holders, journalists, and politicians. We covered SIM swapping in detail here.
- SS7 interception — The Signaling System 7 protocol, which underlies global mobile routing, has known vulnerabilities that allow call and SMS interception by parties with access to telecom infrastructure. Nation-state actors and sophisticated criminal groups have demonstrated this capability.
- Real-time phishing — An attacker operates a fake login page that captures your password and SMS code simultaneously, relaying them to the real site before the code expires. Because SMS codes offer no verification of which site you're authenticating to, you have no cryptographic defense against this.
SMS 2FA is significantly better than no 2FA against opportunistic attackers. Against a motivated adversary willing to SIM-swap or run a phishing kit, it provides minimal protection. Use it when nothing better is offered; replace it whenever you can.
TOTP: Time-Based One-Time Passwords
TOTP (defined in RFC 6238) works differently from SMS. When you set up 2FA with an authenticator app like Aegis, Authy, or Google Authenticator, the service shows you a QR code containing a shared secret. Your authenticator app stores that secret. At login time, both your app and the server independently compute HMAC-SHA1(secret, floor(unix_time / 30)) and compare — a new six-digit code every 30 seconds, no network required.
Because the code is derived from a secret stored on your device (not transmitted over cellular networks), SIM swapping and SS7 attacks don't work against TOTP. This is a meaningful improvement.
The remaining weaknesses are:
- Real-time phishing still works — TOTP codes are valid for up to 90 seconds (most implementations accept one period before and after the current window). A phishing site that relays your code in real time can still use it. TOTP does not verify the identity of the site you're authenticating to.
- Shared secret theft — If an attacker compromises the service's database and obtains the TOTP secrets, they can generate valid codes for every user. This has happened at least once in high-profile breaches.
- Device compromise — If your phone is compromised (malware, unlocked device), your TOTP secrets are exposed.
TOTP is a substantial improvement over SMS for most users and threat models. Its primary remaining vulnerability — phishing — is where hardware keys and passkeys do something fundamentally different.
Hardware Security Keys: FIDO2 and WebAuthn
Hardware security keys (YubiKey, Google Titan Key, and equivalents) implement the FIDO2/WebAuthn standard. The cryptographic mechanism is categorically different from both SMS and TOTP.
When you register a hardware key with a site, the key generates a unique public/private keypair for that specific origin (the domain name). The private key never leaves the hardware device. At authentication time, the browser sends the key a challenge that includes the origin, and the key signs it with its private key for that domain. The server verifies the signature.
The critical property: the key signs a payload that includesrpId— the relying party's domain name. If you're on a phishing site atlogin-google.evil.com, the key will refuse to sign a challenge claiming to begoogle.com. Phishing attacks are cryptographically blocked. FIDO2/WebAuthn specification, W3C
This makes hardware keys the only common second factor that defeats real-time phishing. No other widely deployed mechanism does this.
Hardware keys do have practical limitations:
- Physical loss — if you lose your only key and have no backup, account recovery depends on the service's fallback. Keep a backup key.
- Cost — a quality hardware key runs roughly $25–$60 USD. Not a barrier for high-value accounts; worth considering for general use.
- Not all services support them — hardware key support (FIDO2/WebAuthn) is common among major services but not universal.
Passkeys: Hardware Key Concepts, Software Delivery
Passkeys are an evolution of the WebAuthn standard designed to work without a separate hardware device. Instead of a dedicated key, your phone, laptop, or password manager stores the private key material. The same origin-binding property applies: the private key for example.com will only sign challenges from example.com.
Passkeys are often described as a password replacement rather than a second factor, because they combine something you have (the device holding the private key) and something you know or are (the PIN or biometric that unlocks the device). We covered passkeys in depth here.
The main trade-off compared to dedicated hardware keys is the attack surface: passkeys stored in a cloud-synced keychain (iCloud Keychain, Google Password Manager) are accessible from multiple devices, which is convenient but means a compromised account on that sync platform exposes the passkey. Hardware keys with resident keys store credentials on the device only — no sync, no cloud extraction.
How They Compare
| Method | SIM Swap | Phishing | Device Compromise | Ease of Use |
|---|---|---|---|---|
| SMS | ✗ Vulnerable | ✗ Vulnerable | ✗ Vulnerable | ✓ Easy |
| TOTP | ✓ Resistant | ✗ Vulnerable | ~ Partial | ✓ Easy |
| Hardware Key (FIDO2) | ✓ Resistant | ✓ Resistant | ✓ Resistant | ~ Moderate |
| Passkey | ✓ Resistant | ✓ Resistant | ~ Depends on sync | ✓ Easy |
Which Should You Use?
The answer depends on your threat model and which accounts matter most.
For high-value accounts — email, financial accounts, domain registrar, password manager master account — a hardware security key is the strongest widely available option. The phishing resistance alone justifies the cost and minor inconvenience for these accounts. Keep a backup key registered.
For everything else, TOTP via an authenticator app (preferably one that supports encrypted backup, like Aegis on Android) is a solid default. It's a substantial improvement over SMS, requires no additional hardware, and works offline. The TOTP database should be backed up to an encrypted location — losing it while locked out of accounts you've set up with TOTP is a painful experience.
Passkeys are worth adopting as sites add support, particularly when using a password manager that stores them locally. The user experience is often better than TOTP, and the phishing resistance equals hardware keys.
SMS 2FA is better than nothing. If a high-value account offers no other option, enable it. But if the service offers TOTP or WebAuthn and you're using SMS because it was the default — change it.
A Note on Backup Codes
Almost every 2FA system generates one-time backup codes during setup. These are plain-text codes that bypass the second factor, intended for account recovery when you've lost your device. Store them in a password manager or printed and locked away — not in a file on the same device you use for 2FA. Backup codes stored insecurely are a recovery mechanism for you and an attack vector for anyone with access to your device.
For secure communication specifically, second-factor security matters at every layer. End-to-end encryption protects message contents, but account security determines whether an attacker can access your identity in the first place. The two concerns are complementary.