The massive security hole in Google two factor authentication | Hacker News Reader

The massive security hole in Google two factor authentication

tech.kateva.org

44 pointsMaysonL38 comments

I happen to love Google's two-factor authentication, and, every so often, I go through and just revoke all of the "application specific passwords", just to clean things up, and then recreate the five or six that I actually use.

It feels great to know that I've got a single console that informs me what applications and machines can access my gmail - and I don't have to worry about an old laptop out there somewhere with the password cached.

And - what does the author propose as an alternative if not application specific passwords? How else do I let my iPhone's iMap client read Gmail?

The only feature that I'd like more, would be the ability to limit the cookie to something less than 30 days. I'm pretty used to typing in my OTP at work multiple times a day to login to various systems, so having google request me authorizing my system at the beginning of day/week would be fine.

Other than that - I think Google sets the bar in terms of web application security.

> what does the author propose as an alternative if not application specific passwords?

How about limiting each password to a single use? I generate a password so I can check my e-mail with my iPhone - and after that, the password should become unusable. (In fact, bonus points if I receive an alert that someone has tried to use that password.)

That wouldn't work unless the iPhone only has to log in one time, or if you want to have to generate an application-specific password every time you want to check your email.

I honestly have no idea how it works. I thought that the Mail app would login once, and store some sort of 30-day auth token.

Er, no. IMAP requires you to send password (encrypted or no) every time you connect.

FYI, you can authenticate against both Googles IMAP and SMTP submission services using OAUTH.

  * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH

  250-AUTH LOGIN PLAIN XOAUTH

The client has to support it though; can't think of a mail client I've used with oAuth support.

OAuth was added so apps could be built which are able to access other peoples gmail accounts, but without sharing credentials. I believe there are web apps which utilise this OAuth capability, but I haven't come across any desktop apps which use it.

My point still stands though, which is that you can use IMAP without passwords.

They should be "application specific", maybe even with options to choose which parts of Google Services it can access. I don't want my Digsby generated password to be able to access my email via IMAP. It's unlikely to be leaked in plain-text but it's silly to call it application specific.

> what does the author propose as an alternative if not application specific passwords?

Actually restrict the "application specific passwords" to one application.

The definition of "one application" could simple like the protocol (IMAP, CalDAV, Chrome sync, etc), or complex like an application-specific "signature" that changes between implementations/versions, or restricted to an IP address, etc.

The article mentions writing down one of your application-specific passwords, but this is a silly argument, as the entire intention behind the application-specific passwords is that they are only ever seen/used once.

You copy/paste the password it gives you into Pidgin (or whatever you're using it for) and then click "hide" on the box that displays the password, and then you can never see it again. If you trust the machine you're entering in the password so little that you're worried about keyloggers (which copying and pasting might take care of, but I don't know enough about how copy/paste works or how keyloggers work to say), then (1) you should probably not be using that machine to access accounts that you care enough to use two-factor authentication on (because for all you know someone could have installed remote desktop software that would allow them to take control of your accounts the second after you log in, for example), and (2) you can revoke the application-specific password so that they will never work again.

Obviously, using application-specific passwords does make your account less secure, but without them, every single client application, e.g., Pidgin, would need to implement Google's two-factor authentication system in order to be usable. As a user, you are free to choose not to use application-specific passwords at all and get the same security you would if Google had chosen not to allow these application-specific passwords; you just won't be able to use any client applications that don't support them.

The trouble is that Pidgin (in your example) still has access to the password, which means that malware also has access and could copy it out and transmit it elsewhere.

It is still a massive improvement over what was available before though.

This is the point of a randomly-generated application specific passwords: even if someone snarfs it plaintext it's not as useful as compromising your account. You can't do 2-factor authentication with applications that don't support it. You can't do it with, for example, IMAP, period. So instead of someone grabbing your config file and owning your entire google account all they can do is read your mail, which they could have done anyway. In other words, this 2-factor authentication gives you enhanced security with virtually no drawbacks, but this guy is complaining that it's somehow misleading. Google, in this case, has clearly thought this authentication through as much as possible and came out with as well of a designed product as the limitations allow.

> this guy is complaining that it's somehow misleading.

The one thing I will grant the author is that the explanation given for application-specific passwords could be somewhat clearer.

Feel free to call me stupid, but the first time I used the interface after reading the description, I remember not fully understanding what was going on and thinking that I had to choose a particular name to use a password with a particular application. It took me a little more thought about the purpose of these application-specific passwords to understand that that wouldn't make any sense, and these are instead just plain old passwords with labels for personal convenience in case you want to revoke a particular one later.

I like to think of myself as reasonably technically inclined and this still threw me off, so I can certainly imagine how it would really confuse an average user (though the number of average users using this feature is probably pretty negligible).

No, if someone gets the password you've set aside for your IMAP client, they get access to all services. This is factually wrong: "all they can do is read your mail." As someone with Google two-factor auth and an iPhone, I can tell you it's not that sophisticated.

You can label the access key "IMAP key," but that's just the human readable label. There is no functionality tying a key to particular Google services; any key unlocks them all. There should be such functionality, which was one of the points made in this (admittedly flawed) article.

For the record, you are right when you say they don't "own" you account, since they can't change the password. But they do have broad access.

This is true, though I think the grandparent's point was more that it is still a strictly better security situation than before, in that they can't change the password and remove your access to the account, but you can instantly remove their access (by password revocation). I'm not sure if he/she actually meant that all you could do was read the victim's mail, but yeah, he's wrong if so.

Ya, I think that's a good point; we can all agree that two factor auth is a significant win for users and it's good Google has done it.

I just think people should be clear on what the keys can and cannot protect you against. You mentioned revocation -- one thing that will motivate people to do timely revokes is being aware of the potential harm of leaving these keys active after they are compromised. From what I recall of Google's setup process, they don't prominently tell people to be sure to revoke their keys in certain situations, e.g. you lose your iPhone, you lose your iPad, you lose your laptop, etc. It's easy to get the impression while activating 2-factor auth that these keys are more limited than they are and that you don't have to worry too much about them.

> No, if someone gets the password you've set aside for your IMAP client, they get access to all services.

OK, I guess it would be an improvement to record the first-used service and lock it down only to that. Still, with the old model grabbing the password still gave you access to all services; this is definitely not a degradation of security from before.

No... These passwords will not work as login on Google's website. I just generated a one-time-use password. You can not use it to login on Google.com properties.

""" Please use your account password instead of an application-specific password. """

And obviously it will then prompt for your OTOP. Again, this is absolutely no worse than someone getting your Google Account password anyway... and even if they do, they can only use it for select things that are allowed to be used via one-time-use passwords - it's just that we happen to be discussing email and IMAP is a rather large exception. Presumably this isn't the case for other Google services.

(Uh, guys, did you have a different experience or something?)

I didn't say the passwords would actually log you in, just that they can be used across all services, they cannot be for example limited to mail as the person I was responding to stated. So you could use an app specific password across Google's various APIs and app accessible content - Talk/Gchat/Jabber, Blogger, YouTube, Picasa, Reader, and so forth, there's a fuller list in the docs for two-factor auth. (I have personally made app specific passwords for IMAP, Jabber and Reader, and I used to use a third party client to post to Blogger - the passwords are interchangable.)

(I'm not the one who downvoted you, by the way, so I can only guess at why.)

Are you sure that application specific passwords are really locked down to that level? If I steal the application specific password out of your IMAP client, what other Google services can I use it with?

You can't do 2-factor authentication with applications that don't support it. You can't do it with, for example, IMAP, period.

I am not sure about that at all. For imap for example you could be required to submit your password followed by one time code in single login command:

. login youraccount yourpasswordyourotp

So in the password prompt when the client connects you should type in your password + your otp in one step. But that is still two factor authentication. Of course there is no sense in caching/storing such password. It would be less convenient for sure but saying that you can't do 2-factor for imap is exaggeration.

I was expecting an actual "massive security hole". Not a short article saying "I don't really like how this works".

Doesn't seem to be any security hole if you manage your passwords properly. And if you're using two-factor authentication, chances are you don't leave your gmail password on some post-it note somewhere. Silly article.

If you don't like the application specific passwords, then don't create any. The only problem is that all your applications will need to support Google's two factor authentication natively.

Given that most people want to work with existing applications and infrastructure, it's an application specific password is a reasonable compromise. Google aren't in a position to be able to do any better. At least we're getting an incremental improvement.

One thing Google could do is to lock down a particular password to a specific service on first use, and as the author says to be able to revoke a 30-day authentication.

An interesting feature of app-specific passwords -- which helps to mitigate the complaint in the article -- is that if you are logged in with one, you cannot access some core settings to the account without going through the two-factor process. For example, you cannot change the master password, backup email account, or disable two-factor authentication using an app-specific password. So if one gets leaked somehow, you can always recover your account (though of course a lot of damage might have already been done).

Mark Twain said "Put all your eggs in the one basket and --- WATCH THAT BASKET." Its a strategy with pros and cons.

You can use one time passwords if you are really concerned with keystroke loggers.

Where is the hole? How does an attacker use this "hole" to elevate priveleges?

Given a different title I might not hate this story/commentary so much. But this guy is just looking for his 15 warhol minutes...

As other commenters have noted, the argument in the article is ridiculous. If you don't like the feature, dont use it.

That said, I think there are some possible areas of improvement:

1) I agree with the author that the ability to revoke a 30 day session would be excellent. If someone steals my laptop I'd like the option to force 2 factor on that device.

2) I'd like a Windows/Mac OS X authenticator token app. This exists for RSA, I'd like the same for Google. (bonus point for making it different than the token on my phone and allowing me to disable the software remotely)

3) Provide a way for application developers to register that they're the one using this particular one time password and then disallow the use of that password by any other app. (perhaps this could be achieved with OAuth?)

In general I like the Authenticator functionality, I think Google has put a lot of thought into it and I'd love to see them try and push for wider adoption.

Regarding #2: I´ve created a proof of concept in C# on how you can create this app yourself. Feel free to try it out: https://github.com/esp0/googleAuthNet

It's not perfect, but it does allow me to have a memorable password for everyday use that is improved by the two factor authentication, and a more secure but unmemorable one for use by applications. (Admittedly I could achieve the same by using a password safe compatible with my phone.)

It's not perfect, but it's better than nothing.

I partially agree with the author, this does seem like a big deal. I was ecstatic with this feature because I felt like the odds of my email being compromised was near zero but not so much any more.

I have 10+ application specific passwords and I was under the assumption that these were "application specific". I thought that my Google Talk application specific password was linked to the Google Talk services (and couldn't access other areas of my Google Account). The fact that my entire email contents can be leaked via IMAP if any of these generated passwords get out is kind of scary. Yes, it's still much better than before but not nearly as secure as I assumed.

'de-authenticating' a "machine" can be done just by clearing your cookies ! AFAIK, there's nothing machine specific about the two factor authentication ..

It was pretty disappointing for me really .. I would have liked to actually authenticate specific MAC addresses .. but then, I'll take what I've got :)

How would Google have visibility to your MAC addresses?

Obviously they send a street view van by your home.

You wanted to authenticate with your MAC to someone on a different layer2 topology?

You do realize that anyone can change their MAC address right?

Well sorta. You wouldn't be able to login to your Google account with these "application specific passwords", correct? So your mail/google docs are still protected, no?

It's not a problem with 2 factor is it? It's a problem with not having 2 factor authentication with app-specific passwords.

No offense, but if you're writing them down or typing them, you're probably doing it wrong. (not to discount the fact that yes, applications are still storing it somewhere)

No really, I have a dozen application specific passwords and I've never, ever written them down or typed them in by hand.

Hey guys, Google's 2-factor-auth is not oAuth. The functionality that everyone is clamoring for... is the exact technologies used when using Google Accounts properly. Google, behind the scenes, uses OpenID and oAuth to authorize access to parts of your account...

But the application specific passwords are for the "legacy" applications that don't support oAuth properly. The sad thing is that Chrome is one of my biggest users for App-specific-pws.

Reply on news.ycombinator.com