Skip to content
Naked Security Naked Security

Google leaking 2FA secrets – researchers advise against new “account sync” feature for now

You waited 13 years for this feature in Google Authenticator. Now researchers are advising you to wait a while longer, just in case...

The Google Authenticator 2FA app has featured strongly in cybersecurity news stories lately, with Google adding a feature to let you backup your 2FA data into the cloud and then restore it onto other devices.

To explain, a 2FA (two-factor authentication) app is one of those programs that you run on your mobile phone or tablet to generate one-time login codes that help to secure your online accounts with more than just a password.

The problem with conventional passwords is that there are numerous ways that crooks can beg, steal, or borrow them.

There’s shoulder-surfing, where a rogue in your midst peeks over your shoulder while you’re typing it in; there’s inspired guesswork, where you’ve used a phrase that a crook can predict based on your personal interests; there’s phishing, where you are lured into handing over your password to an imposter; and there’s keylogging, where malware already implanted on your computer keeps track of what you type and secretly starts recording whenever you visit a website that looks interesting.

And because conventional passwords typically stay the same from login to login, crooks who figure out a password today can often simply use it over and over at their leisure, often for weeks, perhaps for months, and sometimes even for years.

So 2FA apps, with their one-time login codes, augment your regular password with an additional secret, usually a six-digit number, that changes every time.

Your phone as a second factor

The six-digit codes commonly generated by 2FA apps get calculated right on your phone, not on your laptop; they’re based on a “seed” or “starting key” that’s stored on your phone; and they’re protected by the lock code on your phone, not by any passwords you routinely type in on your laptop.

That way, crooks who beg, borrow or steal your regular password can’t simply jump straight in to your account.

Those attackers also need access to your phone, and they need to be able to unlock your phone to run the app and get the one-time code. (The codes are usually based on the date and time to the nearest half-minute, so they change every 30 seconds.)

Better yet, modern phones include tamper-proof secure storage chips (Apple calls theirs Secure Enclave; Google’s is known as Titan) that keep their secrets even if you manage to detach the chip and try to dig data out of it offline via miniature electrical probes, or by chemical etching combined with electron microscopy.

Of course, this “solution” brings with it a problem of its own, namely: how do you back up those all-important 2FA seeds in case you lose your phone, or buy a new one and want to switch over to it?

The dangerous way to back up seeds

Most online services require you to set up a 2FA code sequence for a new account by entering a 20-byte string of random data, which means laboriously typing in either 40 hexadecimal (base-16) characters, one for every half-byte, or by carefully entering 32 characters in base-32 encoding, which uses the characters A to Z and the six digits 234567 (zero and one are unused because they look like O-for-Oscar and I-for-India).

Except that you usually get the chance to avoid the hassle of manually tapping in your starting secret by scanning in a special sort of URL via a QR code instead.

These special 2FA URLs have the account name and the starting seed encoded into them, like this (we limited the seed here to 10 bytes, or 16 base-32 characters, to keep the URL short):

You can probably guess where this is going.

When you fire up your mobile phone camera to scan in 2FA codes of this sort, it’s tempting to snap a photo of the codes first, to use as a backup…

…but we urge you not to do that, because anyone who gets hold of those pictures later (for example from your cloud account, or because you forward it by mistake) will know your secret seed, and will trivially be able to generate the right sequence of six-digit codes.

How, therefore, to backup your 2FA data reliably without keeping plaintext copies of those pesky multi-byte secrets?

Google Authenticator on the case

Well, Google Authenticator recently, if belatedly, decided to start offering a 2FA “account sync” service so that you can back your 2FA code sequences up into the cloud, and later restore them to a new device, for example if you lose or replace your phone.

As one media outlet described it, “Google Authenticator adds a critical long-awaited feature after 13 years.”

But just how safely does this account sync data transfer take place?

Is your secret seed data encrypted in transit to Google’s cloud?

As you can imagine, the cloud upload part of transferring your 2FA secrets is indeed encrypted, because Google, like every security-conscious company out there, has used HTTPS-and-only-HTTPS for all its web-based traffic for several years now.

But can your 2FA accounts be encrypted with a passphrase that’s uniquely yours before they even leave your device?

That way, they can’t be intercepted (whether lawfully or not), subpoenaed, leaked, or stolen while they’re in cloud storage.

After all, another way of saying “in the cloud” is simply “saved onto someone else’s computer”.

Guess what?

Our indie-coder and cybersecurity-wrangling friends at @mysk_co, whom we have written about several times before on Naked Security, decided to find out.

What they reported doesn’t sound terribly encouraging.

As you can see above, @mysk_co claimed the following:

  • Your 2FA account details, including seeds, were unencrypted inside their HTTPS network packets. In other words, once the transport-level encryption is stripped off after the upload arrives, your seeds are available to Google, and thus, by implication, to anyone with a search warrant for your data.
  • There’s no passphrase option to encrypt your upload before it leaves your device. As the @mysc_co team point out, this feature is available when syncing information from Google Chrome, so it seems strange that the 2FA sync process doesn’t offer a similar user experience.

Here’s the concocted URL that they generated to set up a new 2FA account in the Google Authenticator app:


And here’s a packet grab of the network traffic that Google Authenticator synced with the cloud, with the transport level security (TLS) encryption stripped off:

Note that the highlighted hexadecimal characters match the raw 10 bytes of data that correspond to the base-32 “secret” in the URL above:

  $ luax
  Lua 5.4.5  Copyright (C) 1994-2023, PUC-Rio
                        ___( o)>
                        \ <_. )
  Added Duck's favourite modules in package.preload{}
  > b32seed = '6QYW4P6KWAFGCUWM'
  > rawseed = base.unb32(b32seed)
  > rawseed:len()
  > base.b16(rawseed)

What to do?

We agree with @mysk_co’s suggestion, which is, “We recommend using the app without the new syncing feature for now.”

We’re pretty sure that Google will add a passphrase feature to the 2FA syncing feature soon, given that this feature already exists in the Chrome browser, as explained in Chrome’s own help pages:

Keep your info private

With a passphrase, you can use Google’s cloud to store and sync your Chrome data without letting Google read it. […] Passphrases are optional. Your synced data is always protected by encryption when it’s in transit.

If you’ve already synced your seeds, don’t panic (they weren’t shared with Google in a way that makes it easy for anyone else to snoop them out), but you will need to reset the 2FA sequences for any accounts you now decide you probably should have kept to yourself.

After all, you may have 2FA set up for online services such as bank accounts where the terms and conditions require you to keep all login credentials to yourself, including passwords and seeds, and never to share them with anyone, not even Google.

If you’re in the habit of snapping photos of the QR codes for your 2FA seeds anyway, without thinking too much about it, we recommend that you don’t.

As we like to say on Naked Security: If in doubt / Don’t give it out.

Data that you keep to yourself can’t leak, or get stolen, or subpoenaed, or shared onwards with third parties of any sort, whether deliberately or by mistake.

Update. Google has responded on Twitter to @mysk_co’s report by admitting that it intentionally released the 2FA account sync feature without so-called end-to-end encryption (E2EE), but claimed that the company has “plans to offer E2EE for Google Authenticator down the line.” The company also stated that “the option to use the app offline will remain an alternative for those who prefer to manage their backup strategy themselves”. [2023-04-26T18:37Z]


FYI you “Blacked out” the ownerids in the hex display, but not in the plain text portion.


Ooooer. That image was cropped from @mysk_co’s tweet above :-)

I’ve added extra modesty curtains to my version of the image, just for consistency, and I’ve let our chums at @mysk_co know. They’ve got a Blue Badge… so they might be able to edit the original tweet if they want to.

Thanks for the comment!


Mystery (myskery?) solved. Tommy Mysk said that he used a test account, but redacted the data in the image anyway just to avoid freaking people out (those are my words, not his), then thought it looked weird…

So he unredacted it, but only removed the boxes on the text, not on the hex, thus creating the half-exposed-but-not-dangerous-anyway image in the tweet. Hope that makes sense.

Apparently you can edit tweets if you splurge on a blue splodge, but only for 30 minutes. So it’s locked in forever now… though with no harm done.


This tweet was replied to by Google engineers, stating that it is not true, as the option will not only be optional, but the codes are all going to be E2EE encrypted too.


That’s not right. (You can find the link to Google’s tweet at the end of the article in the box labelled “Update”, together with a summary of what the company actually said.)

Simply put, Google admitted that the account sync feature was indeed released *without any end-to-end encryption (E2EE) capability*, but claimed that the company has “plans to offer E2EE for Google Authenticator down the line”.

Therefore the findings reported in the article are correct. Your 2FA seeds are uploaded and received as plaintext by Google; the company (or someone who shows up at the company with a warrant) could indeed read them out at the other end; and there is currently no built-in option to do the upload with E2EE enabled.

You’re talking about a feature that might arrive in the app in the future (just how long is “down the line”, anyway?) as if it were already available.

But it isn’t available, and unless and until it is, we suggest you avoid the account sync option if possible. That’s the long and the short of it.


And when Google says that something will be available Soon™, it could be mean anything. After all, we were promised soon Google Docs Offline in Firefox seventeen years ago,


Thank you for alerting us to this issue.
‘The codes are usually based on the data and time to the nearest half-minute, so they change every 30 seconds.’ – should that be date not data?


Commendable restraint in not plugging your own free and excellent Intercept X app for Android as an alternative, which does allow encrypted on device backups of the app settings including OTP 2FA accounts, which can then be securely stored on your cloud storage for later retrieval if needed.

So I’ll do it for you…


Sometimes, a little bit less can be quite a lot more :-)

Thanks for your kind words… much appreciated.


Does a green cloud symbol with a tick in it next to my account image in the app state that my data have been synced to the cloud already? In that case, how do we disable or remove it? I never got a question if I wanted to sync, and can’t find anyting else than time code correction in the settings, so I’d like to know how to turn it off/remove it.


Any Goog Auth users able to advise? (You’d like to think that the data won’t get synced until to turn the option on… but for all I know there may be an option elsewhere that enables synchronisation options generally by default. You never quite can tell in this “cloudy” world of ours.)


Do we know if other 2FA apps like Authy or Microsoft Authenticator have E2EE?


Here’s an blog post on how backup and restore work for Microsoft Authenticator:


That document is reasonably complex… but if I have read it correctly, the account data and seeds that get backed up into Microsoft’s cloud are encrypted on your device before they are uploaded… but with a key that is generated by Microsoft on a Microsoft server, that is stored on a Microsoft server, and that is delivered from that Microsoft server to your new device when you needs to decrypt your backed-up accounts. There is no mention of a cryptographic key of your own concocting (e.g. a passphrase or lock code) that you can inject into the encrypt/decrypt parts of the equation. Thus it is not clear whether you can pre-encrypt the uploaded data so that Microsoft *cannot* decrypt it, but it does seem that you can’t.

Is your account data safe against being lost or stolen? You would think so. Is it safe against an outsider downloading it without having authenticated access to your account? You would think so.

Can you be certain it is warrant-proof without your involvement? I couldn’t figure out how it could be, from the document given (though it is from 2019 so YKMV).

Anyone read it thoroughly enough (or used the system attentively enough) to comment on my comment?


I use MS authenticator. There’s nothing available in the app to interfere with the backup function, including encrypting it further to block warrants.
However, the iOS version of the app uses iCloud to store that backup, so a warrant would need to be served to both organisations, I suspect, to recover the seeds.
(My personal opinion is once someone is at that level of effort, you’re doomed)


not that I like to be “that guy” but there is no way they “forgot” to allow encryption, it was built without it by design. I expect it’s based on googs business model of harvesting data for- marketing and other purposes. Who has power to ask goog for data and they don’t refuse? I can think of two governments. And since it’s all stored in clear text,,,, oops and oh oh… are strong possibilities.


Perhaps they just wanted to get it out in time for a big PR splash, and then add the missing bit later if anyone make a fuss? Isn’t it RSA week in San Francisco? Maybe the idea was to time it to grab some of the headlines available, even if not feature complete?


If so they hired the wrong PR person, as goog rips on everyone else for security, while failing in their own house. If I was at RSA (I’m not) every time I saw a goog staff I would say; “hey did you hear goog has a back up tool that has no encryption in transit or at rest. Maybe it “self -identifies” as being secure, lol ,,,” no I’m not sorry.


To be clear, technically the app *does* encrypt in transit. The network exchange is scrambled and tamper-protected using TLS.


Thank you for the correction, they don’t mention tls 1 or,, (if it even matters in this case or not). I’ll let it rest,,, (I guess its like politics, easy to get caught up not liking some entities, and go beyond facts)


I’d like to also ask the question raised above about whether Microsoft authenticator and other apps that offer this ability (including Apple’s built-in function on iPhones which I have heard of but never managed to actually find?) have the same issue.


If you have a secondary device – tablet, old phone, etc., you can install the Google auth app and backup your info to that device from Google auth app to Google auth app.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!