Google’s support of two-factor authentication is extensive, ranging from pre-printed backup keys to interactive, push-based notifications delivered to devices with up-to-date versions of Google Play Services via Google Cloud Messaging.

Before we start discussing Google’s two-factor authentication, let’s first look how Google protects user accounts if two-factor authentication is not enabled. If Google detects an unusual sign-in attempt (such as one originating from a new device located in a different country or continent), it may prompt the user to confirm their account. This can (or cannot) be done in various ways such as receiving a verification code to an existing backup email address that was previously configured in that account. Interestingly, even receiving and entering such a code and answering all the additional security questions Google may ask about one’s account does not actually confirm anything. Without two-factor authentication, Google may easily decline sign-in requests it deems suspicious. From first-hand experience, one is then forced to change their Google Account password. (Interestingly, Microsoft exhibits similar behavior, yet the company allows using two-factor authentication in such cases even if two-factor authentication is not enabled for that account. Weird, but that’s how it works.)

Once two-factor authentication is activated, things change. One is no longer locked out of their Google Account even when traveling, and even if attempting to log in from a new device. So let us have a look at what Google has to offer.

The Low-Tech Solution: Printable Backup Codes

Google offers the ability to generate a bunch of 10 backup codes. These are then displayed in a ready to print format (business card size), allowing users to carry this essential piece of security in their wallet.

Time-Based One-Time Passwords

The time-based one-time password algorithm is an open solution supported by pretty much the entire industry. Even Apple Two-Factor Authentication generates TOTP passwords when the user requests a verification code from device settings.

In TOTP, trusted devices are initialized with a secret. For convenience, the secret can be conveyed as a QR code. Once scanned, the QR code conveys initialization seed to the Authenticator app of the choice.

This stuff is pretty much standard. Google has its own Authenticator app available for Android and iOS, but one can use pretty much any authenticator app on any major platform. For example, Microsoft offers its own TOTP-based Authenticator app for Android, iOS and Windows 10 (both desktop and mobile). Dozens alternative apps exist.

Yes, you can use Microsoft Authenticator on Windows 10 Mobile to generate verification codes for Google Account, and vice versa: using Google Authenticator on Android successfully generates codes to Microsoft Account.

There are several essential things to know about Google’s implementation of TOTP:

• A single TOTP seed may exist at any given time, meaning that multiple authenticator apps can only be initialized with the same QR code
• Generating a new TOTP seed instantly invalidates all previously initialized authenticator apps
• There is no way to revoke trusted status from a given authenticator app without revoking all other authenticator apps initialized with that seed

Google TOTP Security

While the TOTP algorithm is an open industry standard, its implementations vary. In particular, the Android platform may introduce weaknesses allowing hackers to use vectors of attack unimaginable on other platforms.

• Seed data is not saved as part of Android 6.0 backup mechanism
• Despite that, many OEM backup tools will back up and restore Authenticator data. Such backups are often stored unprotected, allowing hackers extracting and restoring sensitive information.
  • This usually within one brand (ASUS, LG etc.) or ROM (e.g. MIUI)
• If one has root access, extracting Authenticator app data is trivial
• If bootloader is unlocked and custom recovery available, a TWRP NANDroid backup can successfully save and restore 2FA data

Google App-Specific Passwords

Google supports individual app-specific passwords for apps and services that do not support two-factor authentication. These passwords are generated on request, and can be revoked individually. There is no limit to number of active app-specific passwords.

App-specific passwords offer limited access to user data. These passwords cannot be used to log in to Google Account via a Web browser, and they cannot be used for performing Google Takeout, initializing a new Android device or restoring a backup.

SIM-Based Authentication

Verification codes can be delivered as text messages (SMS) or phone calls to a trusted phone number. This is similar to what others do, with one important exception: Google does not require verifying a phone number to activate two-factor authentication. This makes it possible for the user to configure their Google Account so that only secure authentication methods are used.

Trusted phone numbers can be added and removed at any time. Each phone number is individually revocable.

SIM-based authentication has the same issues as those we already discussed when talking about Apple’s take on two-factor authentication. The good thing is that Google does not force users to maintain a trusted phone number on their account.

Google Security Key

Google allows using FIDO Universal 2nd Factor (U2F) devices for two-factor authentication. Google Security Key is only supported on desktops and laptops (including Chromebooks) as well as select tablets with OTG functionality that can run Chrome 40 and newer. A USB port is obviously required.

Google Security Key only works in Chrome.

Google Prompt

Last but not least, let us have a look at Google’s newest addition to the family of two-factor authentication methods, the Google Prompt.

Unlike Apple, Google does not have full control over Android, the base operating system. What Google does have, however, is full control over Google Play Services, an essential component installed on most Android smartphones and tablets sold in the Western hemisphere (Amazon being a notable exception).

Google Prompt works by pushing an interactive verification prompt through GCM (Google Cloud Messaging), which is available on Android devices as part of Google Cloud Platform and on iOS devices as part of the Google app.

Google Prompt is now the default and recommended authentication method. It’s by far the fastest and most convenient of them all. Being a simple “Yes” or “No” message delivered to a trusted device, it does not require opening an app or entering codes. If the user cannot receive the prompt, they can easily select a different authentication method (e.g. a code generated in the authenticator app or delivered in a text message).

Once again, there are no verification codes sent via this prompt. Users just confirm or deny the request. Unlike Microsoft implementation, users cannot respond to Google Prompt on locked devices. Both Android and iOS devices must be unlocked in order to confirm the request (this is not always so with Microsoft prompts).

Google Prompt was introduced in 2016, well after the release of Android 7.0 Nougat. However, Google Prompt does not depend on the version of Android. We successfully tested Google Prompt authentication on Android 5.1, 6.0.1, 7.0 and 7.1 (we don’t have devices running earlier versions of Android).

If there is one thing Google could improve is setting up trusted devices. When trying to add a bunch of Android and iOS devices as trusted devices through Google Account, we discovered that Google assumes that the user has a single Android device and (maybe) one iPhone. We were able to add other devices at a later point, but that required quite a lot of work and even triggered some sort of a warning in our Google Account with Google Prompt functionality being temporarily blocked until the next day. At the end, most but not all issues ironed out.

Users can add and remove trusted devices via Google Account Settings in a Web browser, iOS Google App or in Google Settings on Android devices.

Interestingly, when users set up new devices during initial configuration, they are prompted whether they want to make it a trusted device (Android). The same prompt is received when signing in to the Google app on iOS.

Revoking trusted status can be done either online from a different device or from the device itself (via settings or by removing the Google Account from Settings – Accounts).

Quick data sheet:

• Interactive “Yes” or “No” prompt
• Implemented via Google Cloud Messaging (GCM) on Android, Google App on iOS
• NEW: Code delivery now being tested on Android Wear
• Independent of Android or iOS version
• Requires unlocking the device to see the prompt

Google Two-Factor Authentication Conclusion

Google offers a vast number of options to set up authentication. The single least secure setting (phone-based delivery) is available but is not obligatory, allowing the user to configure 2FA in the most convenient or the most secure way, with multiple stops in between. Unlike Apple, Google allows using non-Google devices for authentication. iOS receives full support (TOTP, Google Prompt), while other platforms (BlackBerry 10, Windows Phone, Windows 10 Mobile) will work via offline, TOTP-based third-party authenticator apps.