5 ms·
Multi-factor authentication means choosing from: 1. something you know (password) 2. something you have (phone, yubikey) 3. something you are (biometrics) W
by wting 14y ago
Multi-factor authentication means choosing from:
1. something you know (password)
2. something you have (phone, yubikey)
3. something you are (biometrics)
With Google's two-factor, logging in requires something you know (password) and something you have (phone). The 10 passwords should be locked somewhere physically safe as a fail-safe.
Two-factor authentication protects against password leaks and brute force password attacks.[0] It now takes two security failures to access your account rather than one.
On a side note, this is why secret questions are worthless as a security measure. Backing up a password with another mental fact is still single factor authentication.
[0]: Unless the attackers were able to attain your fail-safe passwords, but unlikely given the entropy and presumably Google's security.
- xyzzyz 14y agoI'm not talking about 10 passwords I have as a backup. I'm talking about 10 application specific password that are used every day by my phone, mail client, xmpp client etc. They just need to intercept any single of these password to compromise my mail account. How's this different from the situation before two-factor authentication?
- marshray 14y agoAll I can figure is it makes it easier to revoke one password without changing all the others.
- bigiain 14y agoI think this is the answer, and I think it would have made sense if they'd called it a "device specific password" instead of an "application specific password". I've got an asp (dsp?) for my phone (which all the applications that need one on my phone use), another for my iPad, another for each of my laptops, home computers, and my work computer. If I lose (or have stolen) my phone, I can revoke the password it knows - without needing to change any of my other devices. Using the word "Application" allows everybody (including, I think, google's own security people) to make the incorrect assumption that the "iPhone mail password" is "specific" to mail - and only allows POP and IMAP to work. Instead, what "application" means is not the easily assumed "a piece of software" interpretation, but the "use to which something is put" interpretation. The decision and management of that "use to which a password is put" is not made nor emforced by Google, but is all up to _me_ (or, as it turned out, to any attacker who could lever one out of me).
- marshray 14y agoRight. AFAICT, there's nothing inherently "specific" about the password at all, that name is mostly just a "serving suggesion" to the legitimate user (one which the attacker is free to ignore). So calling it a "device specific password" doesn't make it any more sensible to me. I'd call it an "alternate weakest-link redundant password" to be precise, but Marketing rarely goes with my suggestions. :-)
- cwb71 14y agoGoogle does intentionally make it a little more difficult to do what you are doing by refusing to ever show you the password again once it has been generated. You have to store that "unmemorizable" sixteen letter password somewhere. The workflow they seem to encourage is that an "application" asks for your password, you open a browser and generate a new ASP, then save it in that app and forget it forever. By "application" they mean "something that asks for your password." Thunderbird or iChat, not IMAP or XMPP.
- sneak 14y agoAccessing your email box is a different matter than taking over the whole account. The former you can generally recover from.
- Tyr42 14y agoThat's the problem though, isn't it? They don't do password specific permissions, so any leak escalates up to taking over the whole account.
- sneak 14y agoNo, ASPs can only be used to access account data available over imap, smtp, xmpp, and other non-web protocols that don't allow cookies/asking for the OTP.
- akgood 14y agoNot true. Read the article :)
- sneak 14y agoThe article says it's fixed.
- akgood 14y agoThe fix that Google rolled out blocks ASP-based logins from accessing a few highly-sensitive pages on https://accounts.google.com https://accounts.google.com, but otherwise, little has changed. With a quick API request, you can still use an ASP to skip just about any other Google web-based login anywhere on the web. Google might have to completely eliminate their Chrome/Android auto-login feature to actually prevent this sort of thing...
- rdl 14y agoThe Google "Application Specific Passwords" are actually complete passwords which give you access to all data in the account, which is the problem.
- deleted 14y ago[deleted]
- simon_weber 14y agoYou are confused by the misleading "application-specific password" terminology. These passwords each allow the same degree of access: the password you use on your phone could be interchanged with the one on your xmpp client. Aside from being able to revoke each independently, there's not much benefit from having many of them. These are not equivalent to 2-factor auth (which grants you the benefits described in an earlier comment). App-specific passwords exist only to allow you, a 2-factor user, to use applications which do not yet support 2-factor auth.
- trotsky 14y agoThe primary purpose is to reduce the impact of password reuse or the user interactively disclosing their password to an attacker. Primarily leaked password hashes and phishing attacks, but it also combats sslstrip style mitm attacks and keyloggers on public computers. Nobody is going around typing in ASPs. It's not designed to mitigate your personal computer being compromised - the only solutions that can move the needle in that situation are far beyond anything normal folks are willing to put up with.