Site icon Sophos News

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

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:

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

  otpauth://totp/Twitter@Apple?secret=6QYW4P6KWAFGCUWM&issuer=Amazon

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 Lua.org, PUC-Rio
                            __
                        ___( o)>
                        \ <_. )
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Added Duck's favourite modules in package.preload{}
  
  > b32seed = '6QYW4P6KWAFGCUWM'
  > rawseed = base.unb32(b32seed)
  > rawseed:len()
  10
  > base.b16(rawseed)
  F4316E3FCAB00A6152CC

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]


Exit mobile version