Google Authenticator: Backup of passcodes in Google Account; but end-to-end encryption is yet to come …

Stop - Pixabay[German]It's a lesson in how things shouldn't really work. The Google Authenticator app enables two-factor authentication for online accounts. In order to be able to use a replacement device with the app if the phone is lost, Google has implemented the option of saving the required passcodes in the Google account in its Authenticator app. What sounds like enthusiasm unfortunately currently has a stumbling block, because the transfer of the relevant passcode to the Google account is done without end-to-end encryption. After criticism from security experts, Google at least wants to upgrade the end-to-end encryption.


Advertising

Backup of passcodes in the Google Account

Google Authenticator was released in 2010 as a free and easy option for websites that require two-factor authentication (2FA). The Google Authenticator app is available for both Android and iOS. The app is intended to increase user security when logging into online accounts.

The problem with this approach, however, is that dealing with the Google Authenticator can become quite complex if the device on which the app is installed is stolen, lost or simply broken. Then the unique code (passcodes) stored on the device by Google Authenticator is lost, and users can no longer log in to the services in question, with two-factor authentication (2FA) set up in Authenticator. While there are security codes during setup that can be used to unlock the whole thing – they are often lost or misplaced.

Google Authenticator Backup

Based on a lot of user feedback, Google then announced a new feature on April 24, 2023 in the article Google Authenticator now supports Google Account synchronizationAfter an update of the Google Authenticator app, users now have the option of backing up the unique code (passcode) stored on the device by Google Authenticator with their Google account. If the device with the installed Google Authenticator app is lost, the required passcode can be synchronized with a new device via the assigned Google account.. Nach einem Update der Google Authenticator-App haben die Nutzer nun optional die Möglichkeit, den auf dem Gerät vom Google Authenticator gespeicherten einmalige Code (Passcode) mit ihrem Google-Konto zu sichern. Geht das Gerät mit der installierten Google Authenticator-App verloren, lässt sich der benötigte Passcode mit einem neuen Gerät über das zugeordnete Google-Konto synchronisieren.

Backup unfortunately unencrypted

Unfortunately, the Google developers fell a bit short, because the transfer of the passcode through the Authenticator app to the user's Google account is unencrypted and thus potentially insecure. Mysk (iOS developer and security researcher) points this out in a tweet. The relevant passage reads:


Advertising

Google Authenticator Backup unsecure

When Mysk analyzing the network traffic during the backup of the passkey, it was noticed that this data is not end-to-end encrypted. The transmission only took place via TLS, so that a man-in-the-middle attack cannot read the data. The security researchers published screenshots in the tweet as well as in this post that show what is transferred during the backup and then ends up in plain text on the Google account. This transfer probably does not contain the seed (or secret code) used to generate the one-time codes.

However, it is unclear whether this seed (the secret) is backed up to the Google account with in plain text. Articles like this one now say that the Authenticator app secrets could also be accessed by Google or third parties – which would allow the same passkeys to be generated. My reading of Mysk's text, however, is that these very "secrets" were not found in the transmitted messages.

At German site heise the editorial team has analyzed the whole thing and writes in this article that they were able to reproduce the problem under Android 13. The TOTP secret was transmitted to Google during synchronization via the network. As a man-in-the-middle, the heise editors were able to detect the secret as Base32-encoded in the data stream.

The unencrypted transmission is critical for further reasons. The transmitted 2FA QR codes usually contain other information such as the account name and the name of the service (e.g., Twitter, Amazon, etc.) that requires for authentication. Google can see all this data, and knows what online services people are using. The same goes for third parties who get access to the Google account. This could potentially serve Google for personalized advertising, the security researchers write.

The security researchers draw the conclusion: The cross-device synchronization of 2FA secrets is convenient, but comes at the expense of privacy. Fortunately, Google Authenticator still offers the option to use the app without logging in or synchronizing secrets. Security researchers recommend using the app without the new sync feature for now.

Google plans to add encryption

Google was startled after Mysk's report. I came across the information on Twitter that Google is now planning end-to-end encryption (E2E) for Authenticator for retrofitting.

Google Authenticator Backup End-to-end encryption planned

A Google spokesperson told German site heise: "End-to-end encryption (E2EE) is a powerful feature that provides additional protection. To ensure we offer all options to our user:s, we've started to introduce E2EE as an option in some of our products, and we plan to offer E2EE for Google Authenticator in the future." The transmission is secured using TLS anyway, he said, so it's encrypted during transmission. But storage is still in plain text. When the end-to-end encryption in the app will come, is not yet certain. So cautious people continue to refrain from backing up the unique codes in the Google account until this issue is resolved and the problem is fixed.


Cookies helps to fund this blog: Cookie settings
Advertising


##1

This entry was posted in Security and tagged . Bookmark the permalink.

Leave a Reply

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