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