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).
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:
"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: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.1Set-Cookie: SMSV=ADHTe-...; Expires=Sat, 02-Apr-2011 14:03:26 GMT; Path=/accounts; Secure; HttpOnlyToday, 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.
- Did not include its lifetime as part of its value, enabling a server side validation of its validity.
- 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.
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.
ReplyDeleteHow 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?
Hi,
DeleteThanks 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!
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.
ReplyDeleteNo 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.
Hi Jacob and thanks for leaving a comment.
DeleteI 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!
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....
ReplyDelete*doesn't matter .... sorry that was a typo, not poor English!
DeleteHi Kelly,
Deletefrom 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!
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.
ReplyDeleteI agree: Google should NOT default to the 'trust this computer for future logins
Deleteray ban sunglasses
ReplyDeletemichael kors handbags
michael kors outlet
ugg boots
columbia sportswear
coach factory outlet
michael kors outlet
kd shoes
pandora charms
michael kors uk
chenlina20170421
20170518 leilei3915
ReplyDeletemont blanc pens
pandora charms
coach factory outlet
michael kors handbags
lacoste shirts
mlb jerseys wholesale
polo shirts
michael kors outlet clearance
cheap mlb jerseys
ugg boots
You can find lots of great articles on close topics at https://nerdymates.com/blog/article-review
ReplyDeleteI agree: Google should NOT default to the 'trust this computer for future logins
ReplyDeleteSend Flowers To Colombia
I learn from a good blog, your blog I have a great inspiration, thank you. Send Gifts To pakistan
ReplyDeleteI really enjoyed reading your article. I found this as an informative and interesting post, so i think it is very useful and knowledgeable. send gifts to pakistan from usa.
ReplyDeleteThanks for this article very helpful. thanks. Verifications IO
ReplyDelete