Can 2FA be bypassed? Brute force, phishing, and what actually holds

Can 2FA be bypassed? Yes. The honest answer has two parts: two-factor authentication raises the cost of an attack by orders of magnitude, and the factors you pick are not equally resistant to the attacks that actually happen. Nobody competent guesses their way past your authenticator app. Real breaches come from relays, swaps, fatigue, and side doors.

MFA is now the default recommendation across IT security, which is exactly why the attacks against it have professionalized. This post runs the brute-force math first, then ranks the attacks that work in the real world, then finishes with what actually holds.

Brute force: run the numbers first

A six-digit code has one million possible values, and a new one appears every 30 seconds. TOTP computes that code from a shared secret — at least 128 bits of randomness — through a keyed hash. An attacker without the secret cannot compute the code offline; there is no hash to crack, nothing stored that reveals future codes. The only avenue is guessing live, against the server, while the window is open.

That avenue is a dead end in any competent implementation. Give the attacker five guesses per window, uninterrupted, around the clock — assuming they already have your password — and the expected lucky hit still takes about two months. Real verifiers do intervene: they rate-limit failed attempts, then lock the account after a small number of consecutive misses, which moves the timeline from months to never. NIST's guidance in SP 800-63B encodes exactly this. Verifiers SHALL rate-limit failed attempts — mandatory whenever the secret is under 64 bits, which a six-digit code is by a wide margin — and generating a new code SHALL NOT reset the failure count.

So "bypassing 2FA via brute force" is, in practice, a story about implementation bugs, not the algorithm. No attempt limit. A code that lives for ten minutes instead of thirty seconds. A per-IP cap that an attacker defeats by spreading guesses across a botnet. Instagram gave the textbook example in 2019: its account-recovery codes were six digits, valid for ten minutes, and capped per IP address — but researcher Laxman Muthiyah spread roughly 200,000 requests across a thousand IP addresses and brute-forced them anyway. ESET's writeup covers the details; Instagram fixed it and paid a $30,000 bounty.

Against TOTP done right, brute force is the attack that does not work. The ones that work are below, roughly in order of how often they succeed.

The attacks that actually work

1. Phishing with a real-time relay. A TOTP code is a bearer string: anyone who sees it within its window can use it. Adversary-in-the-middle kits — Evilginx popularized the design — exploit exactly that. You land on a cloned login page on a lookalike domain. The page is a reverse proxy: it relays what you type to the real site in real time and shows the genuine MFA prompt. You type your code, the kit relays it instantly, and the attacker captures the session cookie — a valid session that survives your password change until sessions are revoked.

This is now an industry, not a hobby. Microsoft's Threat Intelligence analyzed Tycoon2FA, a phishing-kit-as-a-service first observed in August 2023 and run by the group it tracks as Storm-1747. Its campaigns reached over 500,000 organizations per month before a Microsoft–Europol disruption in March 2026. Microsoft's assessment: the kit could bypass nearly all commonly deployed MFA — SMS codes, one-time passcodes, and push notifications alike.

2. SIM swap, against SMS factors. If your second factor is a text message, your factor is your phone number, and phone numbers are controlled by carriers, not by you. An attacker who social-engineers the carrier into porting your number receives your codes from that moment on. Reddit is the canonical example: in June 2018, an attacker compromised several employees' accounts at its cloud and source-code providers by intercepting SMS one-time passcodes. Reddit's own conclusion was blunt — "SMS-based authentication is not nearly as secure as we would hope" — and the incident still exposed a 2007 database backup containing usernames, email addresses, and salted password hashes, as Krebs on Security reported.

3. MFA fatigue, against push factors. Uber, September 2022. Per Uber's disclosure to the SEC, an attacker likely bought an external contractor's Uber password on the dark web — the contractor's personal device had been infected with malware that exposed the credentials — then repeatedly tried to log in. Every attempt pushed a two-factor approval request to the contractor's phone. The requests initially blocked access. Eventually, the contractor accepted one, and the attacker was in, escalating through other employee accounts to elevated access to internal tools including Slack and G-Suite. The factor did its job dozens of times; the human was the component that failed. Number matching and phishing-resistant keys close this hole.

4. Recovery and account flows. The strongest front door does not help if the side door is unlocked. Helpdesk social engineering — the 2023 MGM Resorts breach began with a phone call to an IT helpdesk — weak security questions, and flows that let a user reset 2FA and enroll a new device are where hardened accounts quietly become single-factor. So does any policy where the 2FA code is optional: an optional code is the server announcing that the first factor alone is enough, if the attacker asks nicely. Instagram's 2019 bug lived here too — the recovery flow, not the login flow.

5. Malware on the device. An info-stealer on your phone or PC reads the code as you type it, screenshots the authenticator, or grabs the QR image you use to migrate entries. The Uber password, remember, came from malware on a contractor's personal device. No second factor survives full compromise of the device that generates it — which is why hardware keys keep their private keys sealed behind a touch.

What NIST says

The reference for MFA in IT security is NIST SP 800-63B, the authentication volume of the Digital Identity Guidelines, revised in 2025. The current framing:

• Out-of-band secrets delivered over the PSTN — SMS or voice — are the guidelines' one restricted authenticator. Restricted means the operator must assess the risk in writing, offer every subscriber at least one non-restricted alternative, warn subscribers about the risks, and keep a migration plan for phasing SMS out.
• Verifiers SHOULD check for SIM change, number porting, and device swap signals before sending a code to a phone number.
• OTP and out-of-band authenticators are explicitly not phishing-resistant, because a manually entered code is not bound to the session. An impostor site can relay it.
• Phishing resistance requires cryptographic authentication. The guidelines name WebAuthn, the protocol behind FIDO2 and passkeys, as achieving it by binding the credential to the authenticated domain of the real site.

In short: NIST treats app-generated codes as acceptable, SMS as a liability to be managed toward extinction, and origin-bound keys as the tier that actually defeats phishing.

What actually holds

FIDO2 passkeys and hardware keys. When you register a passkey, the private key is scoped to the site's real domain, and the browser releases a signature only when that domain matches. A relay proxy on a lookalike domain can render a pixel-perfect clone of the login page, but the browser will not sign for the real site's domain there. There is no code to relay and no credential to capture; the relay fails by design, not by luck.

TOTP, done carefully. The seed stays on your device, encrypted, and is never synced to a vendor's cloud in plaintext. Generation is offline, pure math, with nothing to intercept in transit. TOTP cannot beat a live relay, but it is immune to SIM swap, immune to offline guessing, and works with nearly every service on earth — which passkeys still do not.

Implementation hygiene. Rate limits and lockouts that requesting a new code cannot reset. Number matching for push factors. Session revocation whenever credentials change. And no optional states anywhere: a 2FA code that is optional is not 2FA.

For accounts where a takeover means losing money outright — exchanges, wallets, banking — relay phishing is the threat to design around. Our guide to 2FA for crypto covers that case specifically.

How this site maps to that threat model

Most of the attacks above need something to hammer or something to steal on the server side. This site was designed so there is neither:

• The guest generator computes codes entirely in your browser. Paste a Base32 secret, an otpauth:// link, a QR image, or a Google Authenticator export; the code is derived locally, with zero network requests and nothing stored. There is no endpoint that accepts guesses, so there is nothing to brute force, and no server-side secret to breach.
• The encrypted vault is zero-knowledge. Your master password is stretched with salted PBKDF2, keys are separated with HKDF, and entries are encrypted with AES-256-GCM before they leave your device. The server stores ciphertext only, and login hashes use Argon2id. A full server compromise yields unreadable blobs.
• There is no SMS anywhere in the product, so there is no number to swap.
• The whole thing installs as a PWA and generates codes fully offline.

The free tier covers most personal use with 100 folders and 100 entries; Yearly is $24 and Lifetime is $99. The features page has the full breakdown.

Frequently asked questions

Can 2FA be brute forced?

Against TOTP implemented correctly, no. One million possibilities per 30-second window, with a handful of guesses allowed before rate limiting and lockout, makes success vanishingly unlikely. Brute force works only against broken implementations: missing attempt limits, long-lived codes, or per-IP caps that botnets sidestep — as Instagram's 2019 recovery-code bug showed.

Is TOTP phishing-proof?

No. A TOTP code is a bearer string: whoever sees it within its window can use it. Adversary-in-the-middle kits relay codes in real time and capture the session cookie. Only origin-bound cryptographic credentials — FIDO2 and WebAuthn — are considered phishing-resistant.

Why do my 2FA codes fail?

Almost always clocks. TOTP depends on your device's clock agreeing with the server's within the 30-second step; drift past the accepted window and every code is rejected. Sync your device time, then use the code right after it changes. Reusing an accepted code and mismatched algorithm, digit, or period settings are the other common causes — our TOTP deep dive covers them.

Is SMS 2FA safe?

It is better than a password alone, and it is the weakest factor in wide use. NIST classifies PSTN delivery as a restricted authenticator that requires alternatives, and SIM swapping and SMS interception are routine, proven attacks. Use an authenticator app wherever the option exists.

What is MFA fatigue?

An attack on push-based factors: the attacker, already holding your password, floods your phone with approval prompts and waits for you to tap approve just to make it stop. That is exactly what happened at Uber in 2022. Number matching — or switching to passkeys — defeats it.