Adding a phone number to your Google account can make it LESS secure.

Go to the profile of Vijay Pandurangan
Vijay PanduranganBlockedUnblockFollowFollowing
EIR @Benchmark. Formerly: Eng Director & NY Eng Site Lead @Twitter. Founder @MitroCo, TL/M @Google.
21 hrs ago

Adding a phone number to your Google account can make it LESS secure.

Recently, account takeovers, email hacking, and targeted phishing attacks have been all over the news. Hacks of various politicians, allegedly carried out by Russian hackers, have yielded troves of data. Despite the supposed involvement of state-sponsored agents, some hacks were not reliant on complex zero-day attacks, but involved social engineering unsuspecting victims. These kinds of attacks are increasingly likely to be used against regular people. This recently happened to a friend of mine:

Two weeks ago, an ex-colleague (actually, my officemate at Google way back in 2002) — let’s call him Bob — had his Google account compromised while on vacation in Hawaii. With his primary email account compromised, the attacker could have:

  • seized control of his Facebook account, which would have allowed infiltration of a number of accounts based on Facebook login.
  • reset the password and taken control of other accounts (e.g. financial accounts, Twitter) which only require access to the primary email account.
  • read data stored in Google Cloud
  • Terminated (and potentially logged into) into GCE instances.

He used a very strong password (which was never used elsewhere), had a completely independent recovery email (from his alma mater), had hard-to-guess security questions, and never logged in on unknown devices. While Bob didn’t have multi-factor authentication enabled, he had also heeded Google’s suggestions to add a backup phone number to bolster security. As we shall see, rather than increasing his account’s security, the backup phone actually made his account substantially less secure.

Don’t do this unless you also turn on MFA!

The attack

On Oct 1, after a 2h absence from his phone, Bob attempted to check his email and discovered he’d been logged out of his gmail account. Upon trying to log back in, Google notified him that his email password had been changed less than an hour ago.

He then tried to make a call and discovered that his phone service was no longer active. Calling Verizon, he discovered that someone (the attacker) had called less than an hour ago and switched his service to an iPhone 4. Verizon later conceded that they had transferred his account despite having neither requested nor being given the 4-digit PIN they had on record.

The attacker was able to reset Bob’s password and take control of his account. He or she then removed Bob’s recovery email, changed the password, changed the name on the account, and enabled two factor authentication. (Records show that the account was accessed from IP addresses in Iowa and Germany.)

The attacker’s activities

Eventually, with the help of Google’s customer support and some ex-colleagues who still work at Google, Bob was able to get his account back. All that remained was for us to figure out how the attacker had succeeded, and what lessons we could draw about security practices.

Telco: you are the weakest link.

If the attacker didn’t know Bob’s security questions, didn’t have access to his recovery email, and didn’t know the answer to other “metadata” questions (such as: when did Bob open the account?), how did Google allow the attacker to take over the account, and why did the subsequent set of actions (immediately change the name, recovery email, phone number, and MFA settings) not raise suspicions?

Using a few old Google accounts, I experimented with Google’s account recovery options and discovered that if a Google account does not have a backup phone number associated with it, Google requires you to have access to the recovery email account OR know the security questions in order to take over an account. However, if a backup phone number is on the account, Google allows you to type in a code from an SMS to the device in lieu of any other information.

There you have it: adding a phone number reduces the security of your account to the lowest of: your recovery email account, your security questions, your phone service, and (presumably) Google’s last-ditch customer service in case all other options fail.

There are myriad examples of telcos improperly turning over their users’ accounts: everything from phone hacking incidents in the UK to more recent examples. Simply put, telcos can be quite bad at securing your privacy and they should not be trusted.

Interestingly, it appears that if two-factor-auth via SMS is enabled, Google will not allow your password to be reset unless you can also answer a security question in addition to having access to a phone number.


In order to secure your Google account, you should really enable two-factor auth, and use a TOTP app like Google Authenticator, Duo, or Authy. If, for whatever reason, you don’t have two-factor authentication enabled, I would strongly recommend not adding a backup phone to your account as it could ironically reduce the security of your account. SMS-based two-factor auth is risky also: if an attacker can convince your telco to turn over your phone number to him/her, he/she will have access to your two-factor codes as well.

This pattern seems like something security software should be able to detect: a password reset with incomplete information, followed immediately by a change in recovery email, name, and two-factor-auth settings, coupled with a “my account has been compromised” help request is highly suspicious. I’m curious how often this sequence of events happens during account takeovers, and why Google doesn’t temporarily disable accounts so impacted until a human reviews activity.

  • BlockedUnblockFollowFollowing
    Go to the profile of Vijay Pandurangan

    Vijay Pandurangan

    EIR @Benchmark. Formerly: Eng Director & NY Eng Site Lead @Twitter. Founder @MitroCo, TL/M @Google.

  • Follow
    Vijay Pandurangan

    Vijay Pandurangan

    technology et cetera

    Previous Post
    Next Post