4 ms·

The article mentions writing down one of your application-specific passwords, but this is a silly argument, as the entire intention behind the application-speci

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

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