Your Authenticator Should Not Need Your Account

You did the right thing. You turned on two-factor authentication, installed the app the site itself recommended, scanned the QR codes, and now every login asks for a six-digit number that changes every thirty seconds. Your account is far harder to break into than it was yesterday.

Now answer a question almost nobody asks: if your phone disappears today, where do those numbers come from tomorrow?

For most people using Google Authenticator, the answer is: from Google's cloud, restored through your Google account. Which is, very probably, one of the accounts those codes are meant to protect.

Read that again slowly, because this is where the problem lives.

The key locked inside the vault

A second factor exists for one reason: to guarantee that the password alone does not open the door. It is an independent lock. The whole idea rests on that word — independent.

When your authenticator syncs through your Google account, that independence is gone. The codes and the account now share a single fate. Lose access to the account and you lose, with it, the mechanism that would have won it back. This is not a theoretical security risk, it is an architecture problem: you strapped the parachute inside the bag that is falling.

A second factor that depends on the first is not a second factor. It is the same factor with extra steps.

What TOTP actually is

Here it is worth clearing up a misunderstanding that props up the entire problem. People assume the authenticator app owns the second factor. It does not.

That QR code you scan is not magic: it is a short piece of text, a secret key shared between you and the service. The standard that turns that secret into six digits is public and documented — RFC 6238. The computation is identical everywhere: take the secret, take the current time, run the function, out comes the code.

The secret is the secret. The app is just the wrapper.

That has two practical consequences that change how you should think about this.

First: no app owns your account. If you hold the secret, you generate the codes wherever you like. Switching authenticators is not migrating a service, it is copying a piece of text from one place to another.

Second, and this is the one people miss: you can keep the same secret in more than one app on purpose. Two devices, two authenticators, the same codes, synchronized by nothing but the clock. That is not a hack or a security flaw — it is deliberate redundancy, and it is the simplest answer to the fear of losing your phone.

The exit cost nobody mentions

If you are already inside Google Authenticator and want out, brace for friction that sounds small when described and is large in practice.

The app does have an export: it generates a QR code carrying several accounts at once. But that screen is protected against capture — Android's FLAG_SECURE blocks screenshots. Your way out is photographing the screen with a second device.

And here the real problem shows up: the more accounts you pack into a single QR, the denser it gets. With a dozen accounts, the code becomes a mesh too fine to be read from a handheld photo of a screen, with glare and blur in the way. It simply will not decode.

What works is exporting in batches of three or four accounts at a time. It works, but it is tedious — and the tedium is exactly the point. There is no technical barrier stopping you from leaving. There is just enough friction for most people to give up halfway. That is a form of lock-in too, and it deserves to be named before you choose where to keep the next ten years of your secrets.

What to use instead

The criterion is not brand, it is architecture. A decent authenticator needs three properties:

• It asks for no account at all. No login, no mandatory cloud, no tie to a provider. If it has no account, there is no account for you to lose.
• An exportable backup you control. An encrypted file you keep where you want — a USB stick, a physical safe, your own backup. Not somebody's cloud.
• Serious, verifiable encryption. Key derivation that resists brute force, and an authenticated mode, so the file cannot be tampered with without you noticing.

Aegis, on Android, meets all three. It is local, asks for no account, and its backup is encrypted using scrypt to derive the key and AES-GCM to encrypt and authenticate the contents. You end up holding a file, and the file is genuinely yours. It is what we recommend.

But notice what is actually being recommended: not an app, but the property of not depending on anyone to recover what is yours. Any authenticator with those three characteristics solves it. Aegis is the cleanest implementation we know of, not an article of faith.

The honest caveat

It would be easy to end the article here, and it would be incomplete.

A software authenticator — Aegis included — keeps the secrets in a file on your device. Malware running with your permissions can reach that file. Encryption protects the backup at rest; it does not protect against a program already inside, running as you.

The only genuinely inextractable copy is the one living on a physical security key. The secret is generated inside the hardware and never leaves it — not even for you. There is no file to copy, no process memory to read, and phishing fails because the key cryptographically verifies who it is talking to.

So the recommendation is not to swap one for the other, but to combine:

• Physical keys on critical accounts — primary email, domain registrar, bank, payment platform. Always two keys, never one.
• A local authenticator for everything else, which is most things — the dozens of services that do not accept a hardware key or do not justify one.
• Printed recovery codes for the day both of those fail.

Swapping Google Authenticator for Aegis fixes the circular dependency. It does not fix malware extraction. Those are two different problems, and it is worth knowing which one you are solving.

How to migrate without losing anything

The golden rule: never delete the old one before confirming the new one works. During migration, having the same secret in both apps is the safe state, not the risky one.

1. Install the new authenticator without touching the old one.
2. Export in batches of three or four accounts. Do not try to move everything in one QR — it will not be readable.
3. Verify account by account that both apps show the same six digits at the same moment. If they match, the secret transferred correctly.
4. Make the encrypted backup of the new authenticator and store it off the phone.
5. Test the restore on another device, or at minimum confirm you can open the file with the passphrase. A backup never tested is not a backup.
6. Only then remove the accounts from the old app.