5 ms·

The massive security hole in Google two factor authentication

44 points by MaysonL 15y ago

mchusma 15y ago
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.
markfenton 15y ago
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.
ghshephard 15y ago
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.
- pavel_lishin 15y ago
  > 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.)
  - FaceKicker 15y ago
    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.
    - pavel_lishin 15y ago
      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.
      - Mavrik 15y ago
        Er, no. IMAP requires you to send password (encrypted or no) every time you connect.
        mike-cardwell 15y ago
        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
        ConstantineXVI 15y ago
        The client has to support it though; can't think of a mail client I've used with oAuth support.
        mike-cardwell 15y ago
        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.
- tlrobinson 15y ago
  > 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.
FaceKicker 15y ago
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.
- rlpb 15y ago
  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.
  - wickedchicken 15y ago
    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.
rlpb 15y ago
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.
unreal37 15y ago
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.
lazylland 15y ago
'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 :)
- tshtf 15y ago
  How would Google have visibility to your MAC addresses?
  - RyanKearney 15y ago
    Obviously they send a street view van by your home.
- dfc 15y ago
  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?
jwatzman 15y ago
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).
orofino 15y ago
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.
- espo 15y ago
  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 https://github.com/esp0/googleAuthNet
dfc 15y ago
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...
dfischer 15y ago
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?
watty 15y ago
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.
drivebyacct2 15y ago
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.
teyc 15y ago
It's not a problem with 2 factor is it? It's a problem with not having 2 factor authentication with app-specific passwords.

44 points by MaysonL 15y ago

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.

markfenton 15y ago

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.

ghshephard 15y ago

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.

pavel_lishin 15y ago
> 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.)
- FaceKicker 15y ago
  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.
  - pavel_lishin 15y ago
    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.
    - Mavrik 15y ago
      Er, no. IMAP requires you to send password (encrypted or no) every time you connect.
      - mike-cardwell 15y ago
        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
        ConstantineXVI 15y ago
        The client has to support it though; can't think of a mail client I've used with oAuth support.
        mike-cardwell 15y ago
        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.
tlrobinson 15y ago
> 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.

FaceKicker 15y ago

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.

rlpb 15y ago
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.
- wickedchicken 15y ago
  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.

rlpb 15y ago

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.

unreal37 15y ago

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.

lazylland 15y ago

'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 :)

tshtf 15y ago
How would Google have visibility to your MAC addresses?
- RyanKearney 15y ago
  Obviously they send a street view van by your home.
dfc 15y ago
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?

jwatzman 15y ago

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).

orofino 15y ago

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.

espo 15y ago
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 https://github.com/esp0/googleAuthNet

dfc 15y ago

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...

dfischer 15y ago

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?

watty 15y ago

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.

drivebyacct2 15y ago

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.

teyc 15y ago

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