MFA: why your Google Authenticator app betrays you

A client proudly shows me his phone. Google Authenticator, twenty-odd accounts inside, backup synced. “I’m locked down.” Three weeks earlier, his Google account had served as the front door: a fake document-share email, a login page that looked exactly like Google’s, a six-digit code copied without a second thought. The attacker broke nothing. The client handed him the code, in real time, the way you hand your keys to a valet. And his “lockdown” was synced to the very account that had just fallen.

The usual trap

“I turned on 2FA, I’m protected.” That’s the sentence I hear most often during audits, and it’s the most dangerous one in the personal-security vocabulary. Not because it’s false in the strict sense — MFAMulti-factor authentication: combining two independent proofs of identity to log in.See glossary really does cut your risk compared to a bare password. But because it files dramatically different mechanisms into a single “protected / not protected” box, when they have nothing to do with each other in terms of robustness.

MFA is not one category, it’s a spectrum. At one end, the SMS code, which collapses at the first SIM swapAttack where a fraudster convinces your carrier to port your number to their SIM.See glossary. In the middle, TOTP6-digit code generated every 30 seconds by an app (Google Authenticator, Authy, etc.).See glossary — those six-digit codes that change every thirty seconds, the famous Google Authenticator. At the other end, FIDO2Strong authentication standard using hardware cryptographic keys, phishing-resistant.See glossary, a hardware key or a passkeyConsumer FIDO2 implementation: auth key stored and synced by Apple/Google/Microsoft.See glossary that physically refuses to authenticate on the wrong domain. Between SMS and FIDO2 there are two orders of magnitude of difference in phishingSocial engineering attack pushing targets to disclose credentials or execute code.See glossary resistance. Throwing all of that into the same “2FA” bag is like saying “I have a lock” without specifying whether it’s a bathroom hook or a certified deadbolt.

The practical consequence runs in two directions, and both faces are bad. On one side, people who believe they’re protected and therefore never invest in real protection, because they think the box is already checked. On the other, the illusion that collapses at the worst possible moment — during a targeted attack, while traveling, on the account that pilots their entire digital life. TOTP is not useless. But selling it as game over is the root of the problem.

The trap also feeds on a category error that the industry actively encourages. Marketing speaks of “two-factor authentication” as if the number two were the point. It isn’t. What matters is not how many factors you stack, it’s what each factor actually resists. A password plus an SMS code is “two factors,” and a single AiTM proxy walks straight through both at once. A FIDO2 key alone, on the other hand — one factor — defeats that same proxy by construction. Counting factors is the wrong metric; the right question is “what attack does this stop, and what attack does it not?” The day you start asking that question per account instead of toggling a global “2FA on” switch, the whole picture changes — and so does where you spend your money and your hour of effort.

The real threat model: what walks straight through TOTP

The fundamental misunderstanding is believing that TOTP protects against phishing. It does not. It protects against one specific thing — password theft with no real-time interaction with the victim — and that’s all. Against an attacker who’s talking to you at the exact moment you log in, the six-digit code is one more thing to copy, not a wall.

Here’s the concrete mechanism, the one I see in the case files. The attacker does not build a static fake page that harvests your password to replay it later. He stands up a reverse-proxyAttack where an actor interposes between two parties believing they're communicating directly.See glossary between you and the real service — this is what’s called an adversary-in-the-middle (AiTM) attack. You land on a page that is, byte for byte, the real login page: it isn’t a copy, it’s the real page relayed in real time. You type your username, the proxy forwards it to Microsoft or Google. The real service asks for the TOTP code. You type it. The proxy forwards that too. The service validates and returns an authenticated session cookie — and it’s that cookie the attacker captures. He now holds your live session. The six-digit code was already consumed; he doesn’t care, he has something better: he’s logged in as you, without ever having to go back through MFA.

This tooling is not reserved for nation-states. Open-source frameworks like EvilginxSocial engineering attack pushing targets to disclose credentials or execute code.See glossary do exactly this, turnkey, with pre-built “phishlets” for Office 365, Google Workspace, Okta, all the major providers. The AiTM phishing kit rents on a subscription on criminal forums — “phishing-as-a-service,” with hosting, a valid TLSTransport encryption protocol, basis of HTTPS and modern web security.See glossary certificate for the lure domain, and a dashboard to harvest the stolen sessions. The technical bar to bypass your TOTP has dropped to the level of a motivated script-kiddie. Microsoft has documented AiTM campaigns hitting tens of thousands of organizations. This is neither theoretical nor rare.

The detail that hurts in this scenario is that every reflex you were taught to spot phishing fails here. The TLS padlock in the address bar? Present — the attacker has a genuine certificate for his lure domain. The page that “looks real”? It is real, relayed pixel for pixel. The TOTP code you type “because it’s clearly the right site”? It transits straight through. And even the push approval notification, supposedly “safer” than TOTP, solves nothing: the attacker triggers the legitimate login at the precise moment you approve, so you approve his session believing you’re approving your own. That’s “MFA fatigue” in its surgical form. Anything that relies on a human copying or approving a secret at the right moment is vulnerable, because the human cannot tell the right moment from the wrong one when the proxy is flawless.

Number matching — the feature that asks you to type a two-digit number shown on the login screen into your authenticator app — was rolled out precisely to blunt blind push approvals. It helps against the spray-and-pray “approve, approve, approve until they cave” pattern. It does nothing against AiTM. The proxy simply relays the number the real service displays, your app shows the same number, you match it, and the session cookie still lands in the attacker’s hands. The lesson is consistent across every iteration: each time the defenders add a step that a human performs, the proxy learns to relay that step too. You cannot patch your way out of a structural problem with more human steps. The only fix is to remove the human’s ability to be relayed — which is exactly what FIDO2 does and nothing built on shared secrets can do.

And before anyone reaches for SMS as the comparison baseline, remember that the bottom of the hierarchy is worse than “phishable.” SMS isn’t only defeated by AiTM; it’s defeated by SIM swap, where the attacker doesn’t even need you online — he social-engineers your carrier into porting your number to his SIM, then receives your one-time codes directly. It’s defeated by SS7-network attacks, where signaling-layer access lets a well-placed adversary intercept text messages without touching your phone or your carrier’s front desk. SMS as a second factor combines every weakness: phishable in real time, interceptable at the network layer, and stealable through a phone call to a support agent. It is the one rung you should treat as effectively no second factor at all on anything that matters.

You also have to kill a stubborn piece of folklore: “TOTP is mathematically solid, therefore the TOTP app is solid.” The two statements have nothing to do with each other. Yes, the RFC 62386-digit code generated every 30 seconds by an app (Google Authenticator, Authy, etc.).See glossary algorithm is rock-solid — an HMAC over a time counter, nothing to argue with. But the robustness of an authentication factor isn’t measured by the strength of its algorithm; it’s measured by what it takes to bypass it under real conditions. And under real conditions, nobody breaks the HMAC: you intercept the code in transit, or you steal the seeds at rest. A perfect algorithm protects nothing if the secret it handles leaks out the sides.

And that’s only the online vector. TOTP has a second Achilles’ heel, more mundane: the cloud backup. It’s exactly my client’s trap in the opening. When you sync Google Authenticator with your Google account, or Authy with your Authy account, your TOTP seeds — the secrets that generate the codes — leave your phone to live in a cloud. From that point on, your “second factor” is no longer independent of the first: compromising the cloud account compromises every one of your codes in a single move. You’ve turned a possession factor into an extension of your email account. The day that account falls — phishing, reused password, breach — the attacker recovers the entire vault.

The right approach: tier it, then move what’s critical to FIDO2

The way out is not “delete TOTP.” It’s “stop treating all your accounts the same, and put the real protection where it counts.” First, lay down the robustness hierarchy, worst to best: SMS, then cloud TOTP, then local TOTP, then hardware FIDO2. Each rung climbs a step in phishing resistance. SMS falls to the SIM swap. Cloud TOTP falls with the cloud account. Local TOTP resists remote theft of the seeds but stays “phishable” in real time via AiTM. FIDO2, on the other hand, breaks the AiTM attack by construction.

Why FIDO2 is different and not merely “better”: the WebAuthnBrowser API enabling FIDO2 authentication on websites.See glossary cryptography binds the authentication to the domain. The key signs a response that includes the exact origin of the requesting site. If you’re on login-microsoft.attacker.com instead of login.microsoftonline.com, the signature doesn’t match, and the key refuses — without you having to spot anything, with no human judgment, no “does this URL look weird?” The secret never leaves the hardware element: there’s no code to copy, so there’s nothing to intercept in the proxy. This is what CISA and NISTUS institute publishing reference cybersecurity standards (CSF, SP 800-*).See glossary call “phishing-resistant” MFA, as opposed to everything else. The distinction isn’t marketing, it’s structural.

The pragmatic shift comes down to one rule: anything that can reset the rest goes first. Your primary email is the root — every password reset flows through it. Put it under FIDO2 before anything else. Then the financial accounts, then the password manager, then the admin consoles if you have any. For the rest — the hundreds of secondary accounts where FIDO2 isn’t offered or isn’t warranted — keep TOTP, but local, in an app that doesn’t sync your seeds into a cloud tied to your identity. Aegis on Android, Raivo or Ente Auth on iOS: seeds encrypted on the device, manual encrypted export for backup, no automatic backup into the very account TOTP is supposed to protect. And never, ever the TOTP in the same cloud password manager as the passwords: otherwise a single compromise hands over factor 1 and factor 2 at once.

To make the tiering concrete rather than abstract, draw three circles and put every account you own into exactly one. The inner circle is the root set: primary email, the password manager itself, the mobile carrier account, the bank, the domain registrar, and any cloud or hosting console with administrative reach. These are the accounts from which an attacker can pivot to everything else, so they get the strongest factor you can deploy — FIDO2 hardware, two keys, weak fallbacks removed. The middle circle is everything with real value but limited blast radius: business SaaS, social accounts tied to your name, secondary mailboxes, accounts holding payment details. These get local TOTP at minimum, FIDO2 or a hardware-bound passkey where the service supports it and your exposure justifies the friction. The outer circle is the long tail: forums, newsletters, throwaway services, anything where a takeover costs you an afternoon and nothing more. There, local TOTP is plenty, and honestly even SMS is tolerable because the account isn’t worth an attacker’s real-time effort. The point of the circles isn’t bureaucracy; it’s that you stop spreading the same mediocre protection evenly and start concentrating the strong protection where a compromise would actually hurt.

In practice, the order of operations matters as much as the target, because migration is the moment you lock yourself out through clumsiness. The sequence I have people apply: first, register both FIDO2 keys on the target account while the old method is still active — you never add a strong factor by removing the old one in the same gesture. Then test a full logout / login with each of the two keys, separately, to verify that neither was registered halfway. Then retrieve and store offline the recovery codes the service generates — on paper, not in the manager that itself depends on this account. And only then do you remove the weak methods: SMS, email OTP, and where applicable the now-redundant TOTP. Skip one of these steps and you either lock yourself out or leave a weak door open “temporarily” — and temporary lasts.

The local-TOTP side deserves the same discipline, because its weak point isn’t attack but loss. A local app that syncs nothing is exactly what you want on the security side — and exactly what condemns you the day the phone ends up in a toilet bowl, if you have no backup. The countermeasure is two gestures: an encrypted export of the seeds (Aegis does it in AES, protected by a strong passphrase) stored on an offline medium, and keeping each service’s recovery codes at the moment of enrollment. You don’t need a cloud to survive losing a device; you need an encrypted export you control and a passphrase only you know.

People resist this because “offline encrypted export on a USB drive in a drawer” sounds like more work than “Google syncs it for me.” It is more work — about twenty minutes, once, plus a refresh whenever you add a critical account. Weigh that against the alternative: the syncing convenience is precisely the mechanism that lets an attacker who owns your cloud account download every seed you have, in the clear, from his own machine, without ever touching your phone. The convenience and the vulnerability are the same feature. You can’t keep one and drop the other. So you trade twenty minutes for the guarantee that losing a device is an inconvenience, not a catastrophe, and that a cloud breach can’t vacuum up your second factor. Store the encrypted export in two physical places if you’re cautious — a drawer at home and, say, a relative’s house — so a single fire or theft doesn’t take both your phone and your only backup.

There’s also a subtlety worth naming on the recovery-code front. Most services hand you a block of one-time recovery codes the moment you enable MFA, and most people screenshot them into the phone’s photo roll, which then syncs to the same cloud as everything else — recreating the exact dependency they were trying to break. Recovery codes belong on paper, or in a small offline encrypted file, never in the photo library and never in the cloud password manager that your FIDO2 keys are supposed to be protecting. If your password manager is gated by a hardware key and your hardware-key recovery codes live inside that same password manager, you’ve built a circle with no way in — lose the keys and the codes that would rescue you are locked behind the keys.

That leaves the question of passkeys, because they’ll be sold to you as the universal answer. A passkeyConsumer FIDO2 implementation: auth key stored and synced by Apple/Google/Microsoft.See glossary is FIDO2 under a consumer name: same phishing resistance through domain binding, same WebAuthnBrowser API enabling FIDO2 authentication on websites.See glossary cryptography. The nuance is in the storage. A passkey synced into iCloud or into your Google account inherits the security of that account — which is perfectly fine for your ordinary accounts, and debatable for the handful of accounts whose compromise is precisely the scenario you’re trying to exclude. For those, prefer a non-synced passkey stored on the hardware key itself, or keep two physical FIDO2 keys. For everything else, the synced passkey is an excellent robustness/convenience compromise, and far superior to TOTP.

One last point that isn’t optional: two FIDO2 keys minimum. One you carry, one in backup in a safe place, both registered on every critical account. The classic FIDO2 failure mode isn’t attack, it’s losing the single key that locks you out. One key is a single point of failure. Two keys is resilience.

Buy the two keys at the same time, of the same model, and register both on each account at the moment you enable FIDO2 — not “the primary now, the backup later.” Later never comes, and the gap between “I enabled FIDO2 today” and “I’ll register the spare next week” is exactly when a lost or dead key turns into a lockout. On form factor: a USB-C key for the laptop and an NFC-capable key for the phone covers most people, and several models do both at once. If you travel or work across machines you don’t control, a key that supports both FIDO2 and on-device secrets gives you a single object that handles the critical logins without trusting the host. Keep the firmware and PIN policy in mind too: most hardware keys let you set a PIN that gates the credential, so a stolen key isn’t immediately usable — set it, and don’t make it the same four digits as everything else.

Where you stash the backup key matters as much as having one. Not in the same bag as the primary, ideally not even the same room — the point of a backup is to survive the event that takes out the primary, whether that’s loss, theft, fire, or a bag left in a taxi. A locked drawer at home, a personal safe, or for the most exposed profiles a bank deposit box are all reasonable depending on how much an account compromise would cost you. And keep a written, offline note of which keys are registered where, because the day you need the backup you’ll be stressed, possibly traveling, and definitely not in the mood to remember whether you ever actually enrolled it on the registrar account.

What this means concretely

Mistakes we see all the time

• Syncing your TOTP seeds into the cloud of the account they protect. Google Authenticator backed up to Drive, Authy locked behind SMS: the second factor is no longer independent of the first. One compromise, everything falls.
• Believing TOTP stops phishing. It stops a stolen password replayed later. It does nothing against an AiTM reverse-proxy that relays your code in real time. That distinction is the whole difference.
• Mixing passwords and TOTP in the same cloud manager. Convenient, and that’s the problem: factor 1 and factor 2 in the same basket, a single leak hands over both.
• A single FIDO2 key, no backup. The day you lose it, you’re locked out — or worse, you re-open a weak method “just for now” in a panic and never close it again.
• Enabling FIDO2 on critical accounts but leaving SMS as a fallback. An attacker doesn’t go after your key: he takes the weakest option still available. As long as the weak fallback exists, FIDO2 buys you nothing.
• Forgetting the recovery flow. You hardened the login, not the reset. The helpdesk that re-issues an MFA on three pieces of public information undoes all the work.

Actionable checklist

• N1 List the critical accounts (primary email, bank, password manager, admin consoles)
• N1 Disable cloud backup/sync on the existing TOTP app
• N1 Migrate TOTP to a local app with no cloud sync (Aegis, Raivo, Ente Auth)
• N2 Buy two FIDO2 keys and register both on the primary email
• N2 Physically separate passwords and TOTP seeds (distinct media)
• N2 Move bank and password manager to FIDO2 where available
• N3 Disable SMS and email OTP fallback on accounts moved to FIDO2
• N3 Provision a backup FIDO2 key stored away from the primary home
• N3 Audit and harden account recovery flows (strong identity verification)

Further reading

The distinction between “phishable” MFA and phishing-resistant MFA isn’t an opinion: it’s spelled out in black and white by NIST (SP 800-63B) and detailed by CISA in its guide to implementing phishing-resistant MFA — the two references to read if you have to argue a migration internally. To understand what FIDO2 guarantees cryptographically, go look at the FIDO Alliance specifications; for the exact workings of TOTP and its limits, RFC 6238 is short and readable. And if you still doubt that the AiTM attack is within reach of an ordinary attacker, the public Evilginx documentation is enough to gauge the real level of effort required — which is to say, low.