The Google Authenticator app icon in front of an abstract QR matrix barcode-inspired background. 🅭

Google Authenticator enables device-transfers, no back up/export options

You’ve probably seen calls to “secure your account” with a second-factor authentication (2FA) app all over the web. Online services promote it as a way to improve the security of your online account. After you’ve enabled 2FA, you need to know your username and password as well as a one-time use token (a four–six digit code) generated by your 2FA app.

When you enable 2FA with an online service, it “installs” a secret into your 2FA app — often by scanning a QR-variety matrix barcode. The client app can then generate a one-time use login token derived from the shared secret. You type in that token when you log in to the service. The service can generate its own token following the same process and compare the two login tokens. If a bad actor intercepts the token, it can only be used once and will be worthless in the future.

The default option most places that implement some form of 2FA is Google Authenticator (GA). Or rather, websites will often instruct you specifically to use the GA app. GA uses two open standards — RFC-4226 and RFC-6238 — to derive a single-use log-in token from that shared secret. You can use any app compatible with those standards, but many websites won’t even mention compatibility with anything but GA.

What happens if you lose your 2FA secrets, though? After enabling 2FA, you’ve committed to storing a secret code indefinitely. You’re only storing it inside an app on your phone. Phones get lost, stolen, or replaced every so often, though.

There isn’t a universal answer to this question. Some services will let you remove your 2FA device and let you log in with just your username and password. This approach makes using 2FA completely meaningless. Other services require you to jump through a few hoops and inconveniences before you can remove the 2FA requirement from your account. This approach is less secure than a stricter 2FA policy. It opens the door for someone to social-engineer their way into your account. Other services still will simply not let you log-in anymore if you lose access to your 2FA device. Many won’t let you remove your 2FA device from your account even if you still have access to it!

To make matters worse, it’s often difficult or even impossible to figure out a company’s 2FA policies. In my experience, it’s rarely documented. In my experience, contacting support seldom produces any more detailed insight into the policies and capabilities of their 2FA implementation.

The Google Authenticator app hasn’t had any way to backup, export, or transfer your shared-secrets out of the app. Your 2FA secrets have been bound to a single device. If you’re technically minded, you might have known that you could back up the shared secret by storing copies of the setup matrix barcodes. They contain the shared secret, after all, and can be read by any compatible app.

However, most people won’t realize they need to back up or export their 2FA secrets until after they’ve lost or intend to replace the device they use for 2FA. You may not even remember which online services are protected by 2FA secrets stored on a device after you’ve lost it. You’ll need to keep your old 2FA device around for some time in case you’ll need it to generate a new code for an old login somewhere.

I’ve recommended against enabling 2FA and the Google Authenticator (GA) app in the past. However, there has recently been some positive development in this space. , Google announced that version 5.2 of GA would introduce device-transfers of 2FA secrets.

The new update lets you export your 2FA secrets to a QR-variety matrix barcode that you can scan with the GA app installed on another phone. The export format is entirely undocumented, but I reverse engineered the data in the QR-code and determined it contains a URL-encoded base64-encoded protobuf with all your data.

In my opinion, this proprietary hodgepodge doesn’t meet the General Data Protection Regulation (GDPR) Right to data portability (Article 20) requirement. It states that data portability must be enabled in a structured, commonly used, and machine-readable format. Google tends to flout this requirement, however.

In any case, you now have at least one option for transferring your 2FA secrets as long as you don’t lose your old device before you get a new one. You can’t take a screenshot the QR code in the app to make a simple back up of it. I’m unsure how Google failed to account for phones being stolen, damaged by water, crushed in a door, lost under the bed for 8 months, or had anything else unexpected happen to it.

The GA app’s new solution isn’t perfect but it’s way better than nothing at all! The burden and responsibility to backing up are still placed on unsuspecting users. Users that don’t even get any training or even information about it. You will need to have been burned by this once before you learn of the need to maintain backups.

People don’t have the knowledge required to securely store their 2FA backups. The task poses the same challenges as when backing up your password manager. The exported data are high-value at-risk digital files. You can’t store your 2FA secrets in your regular password manager either. That would defeat the purpose of having a second authentication factor.

In the technology security industry, there’s often talk about the trade-off between security and convenience. 2FA is difficult to use. I recommend against using 2FA — not only the Google Authenticator app – unless you take the time to learn about the technology and can ensure you back up your 2FA secrets. This is inconvenient and it’s difficult and time-consuming to do.