Any opinions expressed here are my own and not necessarily those of my employer (I'm self-employed).

Oct 9, 2011

A Google 2-step verification vulnerability

Early this year Google started rolling out their new two-factor authentication procedure, which they refer to as 2-step verification. On their corporate blog they provided a few hints on why they were rolling out a new authentication procedure — mentioning risks associated with password reuse and phishing attacks. 2-step verification is now widely deployed, by June it was available in 150 countries, and in 40 different languages.

Of course, I took interest in how the two-step verification was designed and I discovered a couple of design issues. In addition I discovered a security flaw that qualified for Google's vulnerability reward program, so I engaged in a responsible disclosure process with Google. Now they've fixed the bug, my reward has been donated to charity, and I've received my 19 bytes of fame, so I guess it's time to blog about this. I'll focus on the security bug here, and blog about the design issues later. I need to do some investigation to see whether Google fixed any of them or not, as they reported that they were re-evaluating some of their design decisions.

If you're unfamiliar with how the two-step verification works, see Google's video below (borrowed from Getting started with 2-step verification).

Now, straight to the point.

The never ending cookie
After you've enabled two-step verification, you'll have to supply a verification code once you've entered your username and password. Note that you can select "Remember this computer for 30 days".

When clicking "Verify", the code would be posted back to Google, and the following response would set a cookie configured to live for 30 days in the browser. Here's the actual cookie used to demonstrate the security bug (I've truncated its value for readability, and other obvious reasons):

Set-Cookie: SMSV=ADHTe-...; Expires=Sat, 02-Apr-2011 14:03:26 GMT; Path=/accounts; Secure; HttpOnly

As you can see, it was set to expire on Saturday, April 2. Here's the note I sent to Google do describe the problem:
I took interest in the option to "remember" the two-step verification for 30 days. Naturally, I've been looking at the cookies used for this purpose, and noticed the cookie set when supplying a valid OTP:
POST /accounts/SmsAuth?persistent=yes HTTP/1.1
Set-Cookie: SMSV=ADHTe-...; Expires=Sat, 02-Apr-2011 14:03:26 GMT; Path=/accounts; Secure; HttpOnly
Today, I reused the above mentioned cookie, which was set to expire in april, four months ago. The cookie still works like a charm, I'm not required to provide a fresh OTP on login, as long as the cookie is set.
"Today" was August 6, so the cookie could definitely be used also after its expiration date. So what went wrong? The problem was that the cookie itself either:

  1. Did not include its lifetime as part of its value, enabling a server side validation of its validity. 
  2. It did include its lifetime, but it was not validated on the server.
The effect was that the lifetime of the cookie was controlled by the browser, and not server side, yielding an "eternal" cookie. This was not Google's intention, and they reported that they "moved quickly" to fix this.

What was the risk?
If we consider the threats that Google specifically mention on their blog, this was not a severe risk. In the case of password reuse across sites, this vulnerability does not reduce the usefulness of the two-step verification. An attacker who stole your password from another site would still need to obtain one of your verification codes (or a verification cookie) to be able to access your account.

The same goes for an attacker that has obtained your username and password through a phishing attack, she would still need to obtain a verification code to compromise your account.

This vulnerability let a (malicious) user circumvent the re-authentication mechanism in 2-step verification. After 30 days, the user must prove yet again that she possesses the mobile phone required to log in to the Google account, assuring that it's still the correct person who's logged in. Re-authentication could be circumvented since it was enforced by the browser. Now it is enforced on the server instead.

And how did Google react?
I have to say, the Google security team was very professional throughout the process. Their e-mails were polite and forthcoming — they were quite open about some of the design choices they'd made. Apparently there was one person assigned to my particular case, which made the follow ups more personal. Thanks to both Adam on the Google security team, and the 2-step verification team!

So, that was the story of my first vulnerability reward-winning bug. In a week or two I'll blog about some design issues that, in my opinion, might have a much larger impact on security.


  1. I have a concern about 2 step verification. Only last week our company was hit by a phishing website attack that fooled our accountant into thinking he was logging into their bank, when in fact he was logging into a fake web site.

    How would 2 step verification stop this? In my mind, the phishing site would simply pass through the login info immediately to the real website, our accountant would get his verification code and enter that into the fake site, and the fake site would push that through to the real bank site as well... Am I missing something here?

    1. Hi,

      Thanks for leaving a comment, your concern is highly relevant. I've been working with online banking security the last couple of years, so I'll share some insights.

      As with other security measures, two-factor authentication is no silver bullet. Still, it's an important piece of the security puzzle for an online bank as it raises the bar for an attacker attempting to transfer money from an account. I gave a talk last year about some of the adjustments we did at the online bank I was working for — in response to some significant developments in trojan functionality. You might want to check it out, you'll find it under "Talks" but here's the direct link: http://www.slideshare.net/klingsen/110502-dnd-isacaisfonlinebankingtrojans

      Trojan attacks are somewhat similar to phishing attacks in that they try to steal a user's password along with several verification codes, so the Trojan countermeasures are highly relevant also for phishing attacks.

      As you point out, if the user gives away the password along with verification codes that's not particularly good for security. However, most banks will require additional codes to transfer actual money from the account — raising the bar for the attackers. Now, there are also other hurdles for an attacker before an attack is successfull and money is transfered. I can't go into specifics, but there are two main categories of security measures, you can try to prevent fraud from happening, or try to detect it in a timely manner. Banks do both.

      Preventive measures are e.g. the verfication codes, which raises the bar for an attacker and requires user interaction. This gives the user a chance to get the feeling that "something funny is going on." If you look at my slides you'll see that we shared information about the transaction through SMS to the user — increasing the likelihood of the user detecting the attack.

      One might argue that this is "detection", but I draw the line at an attempt to transfer money by the attacker. If the user detects the attack and refuses to give up verification codes, the attack has been prevented from the bank's point of view.

      Now, the user might not detect the attack and willingly gives up verification codes. The result will be an attempt to transfer money, and fraud detection comes into play. Note that fraud attacks have existed since the very beginning of banking systems so the problem is far from new. Phishing and Trojan attacks are simply a "new" form of malicious transfers. Banks have been dealing with fraud for ages and have adapted to the new threat. It's worth noting that money is seldom transferred instantly, so there's a reasonable time window to detect the transfer and stop it.

      I can't go into more specifics, but I hope I shed some light on what "makes up" the security of an online bank. Threats are constantly evolving and banks need to adapt their security measures accordingly. As always, you need layers of defense to survive on the Internet.

      I hope everything turned out ok for your colleague!

  2. Google seems to have quietly removed the "Remember this computer for 30 days" option and replaced it with a "Don't ask for codes again on this computer" option that apparently never expires. It's been a lot more than 30 days since the last time I was asked for a verification code.

    No doubt Google made the change to make 2-step verification more attractive to the average user, but it is actually a disconcerting change to me. Now I need to be more careful about whether I check that box when logging into strange PCs. And I wonder what would happen if a hacker got a hold of my password and one of those cookies. Ideally Google would let me set the expiration for my account.

    1. Hi Jacob and thanks for leaving a comment.

      I see that they've changed how 2-step verification works and that the option is now "Trust this computer". You're right, if someone gets hold of your password, along with your cookies or a one time code, that probably means permanent access to your account.

      As I mention in the blog post it seems Google focus primarily on phishing attacks. And for phishing attacks this is not a very problematic change unless the attackers are also able to phish a one time code and use it in near real time. For other types of attacks the change is not so beneficial, for example trojans stealing credentials.

      I've been meaning for some time to write a post discussing the various approaches to authentication that we see from the big players on the Internet. I think I'll have to find some time soon, there's some interesting things going on out there!

  3. I have the two step verification turned on and each time I sign in, I select the "don't ask for codes again from this computer" but this feature never works for me! I still get asked for codes when signing in EVERY time, it don't matter if I had signed in an hour or even a minute before (it even just happened when trying to publish this post even though I had previously been signed in on my computer!) It doesn't seem to "remember" my computer or any of my other devices (phone or iPad). Am I the only one on the planet with this issue? Can anyone shed some light? Thanks in advance....

    1. *doesn't matter .... sorry that was a typo, not poor English!

    2. Hi Kelly,

      from your description this seems to have something to do with your browser settings. Have you set the "delete cookies on exit" configuration option in your browser?

      The two step verification process sets a cookie in your browser in order to "remember it", whenever you log in and this cookie is missing you'll be asked for a new code. You could try this from another browser and see if the problem persists.

      As for the iPad, if you're using Safari in "private mode", I assume that could cause this behaviour.

      Hope that helps!

  4. I think Google should NOT default to the 'trust this computer for future logins'. In the case you would like to retain the 2 step feature, every single time you login you must deselect and It's requiring an additional step. To reset the security settings requires too much effort and not possible to remember what computers you have allowed and what you have not.

    1. I agree: Google should NOT default to the 'trust this computer for future logins


Copyright notice

© André N. Klingsheim and www.dotnetnoob.com, 2009-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to André N. Klingsheim and www.dotnetnoob.com with appropriate and specific direction to the original content.

Read other popular posts