A strong password protects you against exactly one thing: someone guessing it. It does nothing against the ways accounts actually get taken over — a breach that dumps a database of credentials, a phishing page that captures what you type, or a reused password that leaked from some unrelated forum years ago. In every one of those cases the length and randomness of your password is irrelevant. The attacker already has it.

That's the premise behind two-factor authentication: assume your passwords will leak eventually, and build a login that survives it.

Why a strong password isn't enough

Three failure modes make single-factor logins fragile:

Credential stuffing. Attackers take username/password pairs from one breach and replay them against hundreds of other services, betting that people reuse credentials. A generated, unique password per site kills reuse, but it can't help once that specific password leaks.
Phishing. A convincing fake login page captures your password the moment you type it. No amount of entropy defends against you handing the credential over.
Database breaches. When a service is compromised, its stored credentials go with it. If they used weak hashing (or none), your password is readable immediately.

Using a password manager to keep every login long and distinct is still the right baseline — see why you should use a password manager — but a manager reduces the blast radius of a leak. It doesn't stop the leaked credential from working. That's the gap 2FA fills.

What 2FA actually is

Authentication factors fall into three categories:

Something you know — a password, a PIN, a security question.
Something you have — your phone, a hardware key, a passkey stored on a device.
Something you are — a fingerprint, a face scan.

Two-factor authentication means combining two different categories. A password plus a security question is not 2FA — both are "something you know," and both leak from the same breach. Real 2FA forces an attacker to compromise two independent things at once, which is dramatically harder than stealing one string of text.

The 2FA methods, ranked

Not all second factors are equal. Here's how they actually compare.

1. Hardware keys and passkeys (best)

Devices like YubiKeys and platform passkeys use the FIDO2/WebAuthn standard. During registration your device generates a key pair; the private key never leaves the hardware. To log in, the site sends a challenge that the device signs.

The property that makes this special is origin binding: the credential is cryptographically tied to the real site's domain. If you land on paypa1-login.com instead of the real site, the key simply won't respond — there's nothing to phish, because the secret never travels and the browser refuses to sign for the wrong origin. This is why hardware keys and passkeys are called phishing-resistant. They defeat the attack that beats every other method on this list.

2. Authenticator apps / TOTP (the practical default)

Apps like Aegis, Authy, or Google Authenticator implement TOTP (Time-based One-Time Password, an open standard). When you scan the setup QR code, the app and the server exchange a shared secret. From then on, both sides combine that secret with the current time to derive a 6-digit code that rotates every 30 seconds.

Because the math happens locally, TOTP works with no signal and no network. The codes never travel over SMS. For most people this is the right choice: strong, free, and universally supported. Its one weakness is that a sufficiently good real-time phishing page can trick you into typing a still-valid code — which is exactly the case that hardware keys solve.

3. Push approvals (good, with one caveat)

Some services send a "tap to approve" prompt to an app. Convenient, but vulnerable to MFA fatigue (prompt bombing): an attacker who already has your password spams login attempts, hoping you'll tap "approve" out of annoyance. If you use push, enable number matching — where you type a number shown on screen into the app — which neutralizes blind approvals.

4. SMS codes (last resort)

SMS is the weakest common option because your phone number isn't really "something you have." It's SIM swapping: an attacker calls your carrier, impersonates you, and ports your number to their SIM — after which every code lands on their phone. This is a social engineering attack against a support agent, not a technical hack, which is what makes it so effective. SMS also travels over the SS7 telephony network, which has known interception weaknesses.

Use SMS only when a service offers nothing better. It still stops opportunistic credential stuffing, so it beats no second factor.

How to set up 2FA without locking yourself out

The most common reason people avoid 2FA is fear of losing access. Do it in this order and that risk disappears:

Start with your highest-value accounts. Email first — it's the reset path for everything else — then your password manager, then banking and cloud storage.
Prefer an authenticator app or hardware key over SMS whenever the option exists.
Register a second factor as a backup. A spare hardware key, or the same TOTP secret in a second app on a different device. If one is lost, you're not locked out.
Save your backup codes (covered next). These are your parachute if you lose every device.

Storing and sharing backup codes safely

When you enable 2FA, most services hand you a set of one-time backup codes — the way back in if your phone is lost or stolen. They are as powerful as the second factor itself, so treat them like a spare key to your house.

The default advice people follow is the worst: a screenshot in your camera roll, a note titled "codes" on the desktop, or an email to yourself. Any of those turns your backup codes into plaintext sitting in a synced, searchable, breachable place — which defeats the entire point of the second factor.

Better options:

Store them in your password manager's secure notes, attached to the account they belong to.
Print them and keep the paper somewhere physically secure.
If you need to hand codes to someone else — a co-founder, an admin taking over an account, or your own second device — don't email or DM them. Put them in a self-destructing, end-to-end-encrypted note with SnapSend's text share set to burn on read. The link decrypts once and dies, so the codes never linger in a chat log or inbox.

Common mistakes to avoid

Treating password questions as a second factor. Mother's maiden name is public record, not a secret.
Using SMS for your email or password manager. These are your crown jewels — give them your strongest factor.
Keeping backup codes in plaintext on a synced device or in email.
Never testing recovery. Confirm your backup method works before you lose your phone, not after.
Enabling 2FA on one account and stopping. Attackers pivot; secure the whole chain, starting with email.

Quick checklist

[ ] Email, password manager, and financial accounts all have 2FA enabled
[ ] Second factor is an app or hardware key, not SMS, wherever possible
[ ] A backup factor is registered (spare key or second device)
[ ] Backup codes are stored encrypted, never in plaintext or email
[ ] Push prompts use number matching
[ ] You've tested that recovery actually works

2FA isn't about paranoia — it's about accepting that passwords leak and refusing to let one leak become an account takeover. Set it up once, store your backup codes properly, and a stolen password becomes a dead end.

When you do need to move backup codes or any other secret to another person or device, don't paste it into chat. Send it as a one-time, self-destructing link with SnapSend — it decrypts in the recipient's browser and disappears after a single read.