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.
