
The massive security hole in Google two factor authentication - MaysonL
http://tech.kateva.org/2011/07/massive-security-hole-in-google-two.html
======
ghshephard
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
> 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
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
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
Er, no. IMAP requires you to send password (encrypted or no) every time you
connect.

~~~
mike-cardwell
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
The client has to support it though; can't think of a mail client I've used
with oAuth support.

~~~
mike-cardwell
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.

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

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

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

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

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

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

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

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

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

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

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

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

------
lazylland
'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
How would Google have visibility to your MAC addresses?

~~~
RyanKearney
Obviously they send a street view van by your home.

------
dfischer
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?

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

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

