There's something that bugged me about two-factor the moment I activated it. The application specific passwords are stored in plain-text. How does Google know that it's actually e.g. Chrome accessing my mail with a given application-specific password?
If a hacker gets a hold of an old backup of mine, which includes a Pidgin configuration file I forgot to delete, which holds a plaintext password, can he get into my account with that?
If you didn't revoke the application-specific password. And you should be revoking them when you're no longer using them.
If you weren't using application specific passwords, of course, it would have been your actual Google password in that Pidgin config.
It's a little disappointing that the app-specific password isn't more secure, but it's certainly not less secure than foregoing them.
App-specific passwords are bypasses of 2-factor auth. Use them selectively and with care, revoke ones you're not using anymore. And replace them from time to time.
Two-factor authentication is as secure as you make it.
If you value security more than convenience don't use application specific passwords. Google certainly allows for that by only consuming their services through a secure web interface. Is there another mainstream e-mail provider who supports that?
However, if you would like to use apps, gtalk, pidgin, etc. Google will still let you and it will still be more secure than before (revoke specific passwords, etc.).
If one of your application specific passwords (ASPs) is compromised your e-mail content will be compromised but NOT your account as long as your phone / token generator are under your control, allowing you to recover access by your own means. That is a big difference.
That's exactly why I don't use 2-factor. It's only as secure as a single complex token. I use a password manager with complex passwords. I fail to see the added security of enabling 2-factor in this case.
Since I've been downvoted without a response, let me elaborate on my concerns. I haven't seen the threat of application specific passwords (ASP) addressed properly. If an ASP is sniffed or somehow extracted from a device it seems like it's practically equivalent to a single-factor authentication password. I couldn't determine from Google's docs if an ASP will allow you to change a master password or not. Or if it could be used in the place of a master password. It seems like it can only be used through apps that utilize Google APIs. Does anyone know if one of those APIs allows for changing of the master password?
When you need to make any changes to the 2-factor settings, you must enter your account password and the 2-factor password. The ASP cannot be used for this purpose.
Me too. It seems to me that since ASP allows me POP/IMAP access to a gmail account, it probably gives me enough access to run the "send a password reset" attack. I can't use that to 0wn the two-factor protected google account, but I can easily use it to 0wn the AppleID/Anazon/eBay/PayPal account using the gmail account for the recovery address…
Off the top of my head, I don't even know if it's possible to ensure my iPhone or GalaxySII is using SSL/TLS for it's POP/IMAP connections (or if an attacker with brief access to my device could switch it to plain-text-passwords then sniff it's authentication on the local wifi).
Gmail supports restricting POP/IMAP access to specific labels. Couldn't you set up filters to move password reset emails/all emails from services you care about out to non-POP/IMAP folders, skipping the inbox.
Then we should probably move towards (something like) OAuth in all our apps, be it web, desktop or mobile. This way a potential evildoer is left only with a very limited token. Even more, we can invalidate tokens based on time and device used.
Having OAuth or Two factor in Google Talk/Chrome or any application based login system shouldn't be THAT hard. Along with your password, there should be another text field stating "OTP" or some other friendly name.
2FA is equivalent to changing your password every 30 seconds. Yes, it's "only" as secure as that single token, but the entire point of doing 2FA on a separate hardware device is that even if you have every piece of malware installed on the machine you're logging in to, there is still an analog transfer of information from your phone(/keyfob/whatever) to your computer via your brain. It keeps your "password" in two parts, one of which lives in your head/password manager/muscle memory, and the other of which lives on your phone.
ASPs are certainly less secure than 2FA, but they only permit services access, rather than account administration access.
2FA is slightly more hassle for the knowledge that you are effectively protected against a wide range of attacks. It's very worth it.
That reminds me of discussion on desktop security where often root access is seen as they holy grail – while the potential for damage with simple user access gets ignored …
2-step authentication is great but the (wrongly) so-called application-specific passwords are definitely the weakest link in the chain. They do not allow for a full takeover of a Google Apps account but there is still a lot of damage possible.
Two factor limits the time window within which a password is useful. If one of your complex password's hashes gets exposed, someone would need to also know your ssl-only two factor auth cookie, and then reverse/bruteforce your password within the 30 day window the cookie makes it valid for - that makes the "current model" of releasing the hashes on pastebin and crowdsourcing the hash-cracking much more time critical.
Are you asking if a hacker could use the application-specific password to access your email account? I'm pretty sure the application-specific passwords are only good for the service using them (e.g. the first service to use a newly generated password is the only one allowed to ever use it), but that would be trivial to test for yourself.
That can't work - how would they identify the service using them? Ip address is useless for this purpose and other identifiers ar either not available or very easily spoofed and thus equally useless.
If somebody gets hold of the application specific password, he'llbe able to use said application.
I just used the same password to login to my Talk account in Pidgin and later for my Android. This is really insecure, especially when Pidgin saves passwords in plain text.
You're perfectly welcome to use the same password multiple times-- it's as secure as you yourself make it. When Google generates an App password, it displays it once-- and then trashes it. On that same page is a list of the identifiers you've given all of your apps, and the last time that identifier's password was used to log into your account. At any point, you can trash a generated password, and anything using that password can't log into your account anymore.
If you use the same generated password for every application, then you're not in that much better a situation than you would be otherwise. If you use different identifiers for each application, you can identify exactly where a breach happened from by last login time, and disable that password entirely.
Kind of. This is the reason 2-factor makes me uncomfortable too: instead of having 1 username/1 password, it's actually 1 username/lots of passwords. And the passwords generated are all lowercase alphabetic characters (I assume to make them easier for users who don't/can't copy-paste).
It'd make me a lot more comfortable if I could lock each password down to a specific Google service (for instance: generate an OTP for Pidgin, and enable it only for Google Talk), they were a lot longer, and had special chars + numbers in them.
ASPs are 16 characters. That's 26^16 - 26^15 = 4.19315 * 10^22 (41.9 sextillion!) cominbations. If you aren't confident in the size of that keyspace, I'm not sure what to tell you.
The point about permitting a password to be used for only certain services is absolutely a valid one, though.
You are right and that's what I'm going to do. But it's no less secure until you don't "remember" that token anywhere. A remembered password in Google Talk (desktop client) is just encrypted and can be easily recovered.
Edit: To add to my reply, I have never used the remember password for Pidgin in the past, however enabling 2 step auth require me to do that. It'd be great if Google could somehow allow only the first associated app with a password for subsequent uses. Technically that looks very challenging (if at all possible).
this is crazy, doesn't every current linux distro already have a keychain-like-thingy which is protected by the user password?
Adium (which is also based on libpurple) uses it on the mac, which means there is no plaintext password lying around.
That is not possible with the current 2-factor authentication system. App-specific passwords are only called 'specific', they are not really app-specific, i.e. you can use them with any app you like if 2-factor authentication with a token has not been implemented yet.
Comments
There's something that bugged me about two-factor the moment I activated it. The application specific passwords are stored in plain-text. How does Google know that it's actually e.g. Chrome accessing my mail with a given application-specific password?
If a hacker gets a hold of an old backup of mine, which includes a Pidgin configuration file I forgot to delete, which holds a plaintext password, can he get into my account with that?
If you didn't revoke the application-specific password. And you should be revoking them when you're no longer using them.
If you weren't using application specific passwords, of course, it would have been your actual Google password in that Pidgin config.
It's a little disappointing that the app-specific password isn't more secure, but it's certainly not less secure than foregoing them.
App-specific passwords are bypasses of 2-factor auth. Use them selectively and with care, revoke ones you're not using anymore. And replace them from time to time.
Two-factor authentication is as secure as you make it.
If you value security more than convenience don't use application specific passwords. Google certainly allows for that by only consuming their services through a secure web interface. Is there another mainstream e-mail provider who supports that?
However, if you would like to use apps, gtalk, pidgin, etc. Google will still let you and it will still be more secure than before (revoke specific passwords, etc.).
If one of your application specific passwords (ASPs) is compromised your e-mail content will be compromised but NOT your account as long as your phone / token generator are under your control, allowing you to recover access by your own means. That is a big difference.
That's exactly why I don't use 2-factor. It's only as secure as a single complex token. I use a password manager with complex passwords. I fail to see the added security of enabling 2-factor in this case.
Since I've been downvoted without a response, let me elaborate on my concerns. I haven't seen the threat of application specific passwords (ASP) addressed properly. If an ASP is sniffed or somehow extracted from a device it seems like it's practically equivalent to a single-factor authentication password. I couldn't determine from Google's docs if an ASP will allow you to change a master password or not. Or if it could be used in the place of a master password. It seems like it can only be used through apps that utilize Google APIs. Does anyone know if one of those APIs allows for changing of the master password?
A quick search shows that others share my concern about ASPs: http://webapps.stackexchange.com/questions/13317/how-does-ap... http://tech.kateva.org/2011/07/massive-security-hole-in-goog... https://groups.google.com/forum/#!topic/chromebook-central/z...
When you need to make any changes to the 2-factor settings, you must enter your account password and the 2-factor password. The ASP cannot be used for this purpose.
I'm kind of wary of the ASP. It feels very backdoorish. And by the very nature of ASP, it is meant to be saved/stored on the computer system.
Me too. It seems to me that since ASP allows me POP/IMAP access to a gmail account, it probably gives me enough access to run the "send a password reset" attack. I can't use that to 0wn the two-factor protected google account, but I can easily use it to 0wn the AppleID/Anazon/eBay/PayPal account using the gmail account for the recovery address…
Off the top of my head, I don't even know if it's possible to ensure my iPhone or GalaxySII is using SSL/TLS for it's POP/IMAP connections (or if an attacker with brief access to my device could switch it to plain-text-passwords then sniff it's authentication on the local wifi).
Gmail supports restricting POP/IMAP access to specific labels. Couldn't you set up filters to move password reset emails/all emails from services you care about out to non-POP/IMAP folders, skipping the inbox.
A kludge, sure, but a possibility.
Then we should probably move towards (something like) OAuth in all our apps, be it web, desktop or mobile. This way a potential evildoer is left only with a very limited token. Even more, we can invalidate tokens based on time and device used.
Having OAuth or Two factor in Google Talk/Chrome or any application based login system shouldn't be THAT hard. Along with your password, there should be another text field stating "OTP" or some other friendly name.
2FA is equivalent to changing your password every 30 seconds. Yes, it's "only" as secure as that single token, but the entire point of doing 2FA on a separate hardware device is that even if you have every piece of malware installed on the machine you're logging in to, there is still an analog transfer of information from your phone(/keyfob/whatever) to your computer via your brain. It keeps your "password" in two parts, one of which lives in your head/password manager/muscle memory, and the other of which lives on your phone.
ASPs are certainly less secure than 2FA, but they only permit services access, rather than account administration access.
2FA is slightly more hassle for the knowledge that you are effectively protected against a wide range of attacks. It's very worth it.
That reminds me of discussion on desktop security where often root access is seen as they holy grail – while the potential for damage with simple user access gets ignored …
2-step authentication is great but the (wrongly) so-called application-specific passwords are definitely the weakest link in the chain. They do not allow for a full takeover of a Google Apps account but there is still a lot of damage possible.
The two big players here (Vasco and RSA) both do this in hardware and software. So there are soft devices that run on desktops, mobile, etc.
Two factor limits the time window within which a password is useful. If one of your complex password's hashes gets exposed, someone would need to also know your ssl-only two factor auth cookie, and then reverse/bruteforce your password within the 30 day window the cookie makes it valid for - that makes the "current model" of releasing the hashes on pastebin and crowdsourcing the hash-cracking much more time critical.
Are you asking if a hacker could use the application-specific password to access your email account? I'm pretty sure the application-specific passwords are only good for the service using them (e.g. the first service to use a newly generated password is the only one allowed to ever use it), but that would be trivial to test for yourself.
That can't work - how would they identify the service using them? Ip address is useless for this purpose and other identifiers ar either not available or very easily spoofed and thus equally useless. If somebody gets hold of the application specific password, he'llbe able to use said application.
You're right, I'm not sure how I thought that could work.
I just used the same password to login to my Talk account in Pidgin and later for my Android. This is really insecure, especially when Pidgin saves passwords in plain text.
You're perfectly welcome to use the same password multiple times-- it's as secure as you yourself make it. When Google generates an App password, it displays it once-- and then trashes it. On that same page is a list of the identifiers you've given all of your apps, and the last time that identifier's password was used to log into your account. At any point, you can trash a generated password, and anything using that password can't log into your account anymore.
If you use the same generated password for every application, then you're not in that much better a situation than you would be otherwise. If you use different identifiers for each application, you can identify exactly where a breach happened from by last login time, and disable that password entirely.
Kind of. This is the reason 2-factor makes me uncomfortable too: instead of having 1 username/1 password, it's actually 1 username/lots of passwords. And the passwords generated are all lowercase alphabetic characters (I assume to make them easier for users who don't/can't copy-paste).
It'd make me a lot more comfortable if I could lock each password down to a specific Google service (for instance: generate an OTP for Pidgin, and enable it only for Google Talk), they were a lot longer, and had special chars + numbers in them.
ASPs are 16 characters. That's 26^16 - 26^15 = 4.19315 * 10^22 (41.9 sextillion!) cominbations. If you aren't confident in the size of that keyspace, I'm not sure what to tell you.
The point about permitting a password to be used for only certain services is absolutely a valid one, though.
You are right and that's what I'm going to do. But it's no less secure until you don't "remember" that token anywhere. A remembered password in Google Talk (desktop client) is just encrypted and can be easily recovered.
Edit: To add to my reply, I have never used the remember password for Pidgin in the past, however enabling 2 step auth require me to do that. It'd be great if Google could somehow allow only the first associated app with a password for subsequent uses. Technically that looks very challenging (if at all possible).
Sounds as if Pidgin is the problem here.
I know that at first look it sounds like a Pidgin problem, but they do justify their situation quite well on their site: http://developer.pidgin.im/wiki/PlainTextPasswords
this is crazy, doesn't every current linux distro already have a keychain-like-thingy which is protected by the user password? Adium (which is also based on libpurple) uses it on the mac, which means there is no plaintext password lying around.
There is - GNOME has Keyring, KDE has Wallet. But apps need to support it or have a plugin system for that. Pidgin has plugins for GNOME and Windows: http://developer.pidgin.im/wiki/ThirdPartyPlugins#Securityan...
They have a point - if Google really allows other apps to access the account via Pidgin's password, perhaps they should fix that.
That is not possible with the current 2-factor authentication system. App-specific passwords are only called 'specific', they are not really app-specific, i.e. you can use them with any app you like if 2-factor authentication with a token has not been implemented yet.
If Pidgin is your use-case, the only solution is not using Pidgin.