Comment by FaceKicker | Hacker News Reader

Comment by FaceKicker | Hacker News Reader

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.

Reply on news.ycombinator.com