4 ms·

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

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.

FaceKicker 15y ago
> 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).
mapgrep 15y ago
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 15y ago
  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 15y ago
    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.
- wickedchicken 15y ago
  > 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.
- drivebyacct2 15y ago
  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?)
rlpb 15y ago
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?
ajro 15y ago
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.

FaceKicker 15y ago

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

mapgrep 15y ago

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 15y ago
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 15y ago
  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.
wickedchicken 15y ago
> 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.
drivebyacct2 15y ago
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?)

rlpb 15y ago

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?

ajro 15y ago

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.