Two-Factor Authentication: How It Actually Works

Two-factor authentication proves your identity with two different categories of evidence — usually "something you know" (a password) plus "something you have" (a device or key). Here's what's actually happening behind the three common implementations.

SMS codes — the weakest common method

You enter your password, the service texts a one-time code, you enter that too. Simple, but the weakness isn't in the code itself — it's in the delivery channel. SIM swapping — where an attacker convinces (or bribes, or social-engineers) your mobile carrier to transfer your phone number to a SIM card they control — redirects those codes straight to the attacker, no phone theft required. This is a real, documented attack vector specifically targeting high-value accounts (crypto wallets, email accounts used for password resets elsewhere).

SMS 2FA is still meaningfully better than no second factor — it stops the vast majority of automated attacks that only try stolen passwords. It's specifically weak against a targeted attacker willing to attempt a SIM swap, not against the much larger volume of generic credential-stuffing attempts.

Authenticator apps (TOTP) — meaningfully stronger

Apps like Google Authenticator or Authy generate a 6-digit code that changes every 30 seconds, using an algorithm called TOTP (Time-based One-Time Password). When you first set up 2FA, the service and your app share a secret key (usually via a QR code). From that point, both sides independently compute the same code using that shared secret plus the current time — no network request happens at code-generation time, which is exactly why it works without a signal or internet connection.

code = HMAC(secret_key, current_time_window)

Because there's no SMS delivery channel involved, SIM swapping doesn't affect TOTP at all — the attacker would need the actual shared secret, not control of your phone number.

Hardware security keys (FIDO2/WebAuthn) — the strongest common method

A physical device (like a YubiKey) that you tap or insert to authenticate. Unlike TOTP codes, which you could theoretically be tricked into typing into a fake phishing site, WebAuthn performs cryptographic verification tied to the actual domain — the key checks that it's talking to the real accounts.google.com, not a lookalike phishing page, and simply won't respond to the fake one. This makes hardware keys resistant to phishing in a way that TOTP codes and SMS codes fundamentally aren't, since a human can be fooled by a convincing fake page in a way a cryptographic domain check cannot.

Why 2FA blocks most account takeovers

The overwhelming majority of account compromises start with a leaked or guessed password — from data breaches at other services (people reuse passwords), phishing, or brute-force attempts. Any form of 2FA means a leaked password alone is no longer sufficient — the attacker also needs the second factor, which dramatically shrinks the pool of attacks that succeed, even with the weaknesses SMS specifically has.

A practical hierarchy

If a service only offers SMS, use it — it's still much better than nothing. If a service offers an authenticator app, prefer that over SMS. If a service offers hardware security keys (increasingly common for high-value accounts — email providers, password managers, crypto exchanges), and the account is worth protecting against a targeted, sophisticated attacker specifically, that's the strongest widely available option today.

2FA is one of the concrete, high-leverage fixes covered under Broken Authentication in the OWASP Top 10 — worth reading if you're building the login flow that decides whether to enforce it, not just using it as an end user.

Push-based 2FA: a fourth method worth knowing

Many services (banking apps, enterprise identity providers) now offer push-based 2FA instead of a typed code — approving or denying a login attempt directly through a notification on your phone, rather than reading and typing a 6-digit number. This removes the manual-entry step and its associated risk of being tricked into typing a valid code into a phishing site, but introduces a different risk: "MFA fatigue" attacks, where an attacker who already has your password repeatedly triggers push prompts hoping you'll eventually approve one out of annoyance or habit rather than a deliberate decision. Well-implemented push 2FA shows contextual details (the requesting device, location, or a number-matching challenge) specifically to counter this — treat any push prompt you didn't just initiate yourself as a signal your password may already be compromised, not a routine notification to dismiss.

Passkeys: where this is all heading

Passkeys build on the same WebAuthn/FIDO2 cryptographic foundation as hardware security keys, but store the credential in a device's secure hardware (a phone's secure enclave, synced via iCloud Keychain or a password manager) instead of requiring a separate physical key — combining hardware-key-level phishing resistance with the convenience of not carrying a dedicated device. They're increasingly offered as a full password replacement, not just a second factor, at major services. Adoption is still uneven across sites, but where offered, a passkey is generally the strongest and most convenient option available today — worth enabling over TOTP when a service supports it.

Common mistakes

Related reading

• OWASP Top 10, Explained for Developers Who Aren't Security Specialists — shares tags: cybersecurity (same category).
• Android App Permissions: A User's Guide to Staying Safe — shares tags: cybersecurity.
• Big O Notation Without the Math Panic — shares tags: productivity.
• Clean Code Principles That Actually Hold Up in Practice — shares tags: productivity.
• Understanding Cloud Cost Optimization Basics — shares tags: productivity.