86 ms·
Application Specific passwords are designed to solve the case where an application requires you to enter your Google username and password rather than passing y
by ElliotH 15y ago
Application Specific passwords are designed to solve the case where an application requires you to enter your Google username and password rather than passing you to Google themselves to do the authentication.
The obvious risk of this model is what happens if an untrusted client steals that password.
Since you haven't given it your actual Google password It can still access your data, but it can't change your password (you have to enter your main Google password to do that) or change other critical settings, and if the application is misbehaving all you have to do is click revoke, and its gone.
You only have to enter them once because most clients nowadays provide a 'Remember my Password' functionality. Google assumes you will use this, so only need to enter your password once. If the password is forgotten you just generate a new one.
- jerrya 15y agoThanks for the explanation, and sorry, I still am lacking a good model for what is going on. You only have to enter them once because most clients nowadays provide a 'Remember my Password' functionality. Google assumes you will use this, so only need to enter your password once Is this really true? Because the documentation for the one time auth doesn't indicate anything like that. So I am confused as to what is happening in the background on Google's side. My pseudo-model is that their password acceptance library looks for a correctly identified two factor authentication OR a one time password out of the user's one time password table. But then I don't understand why these one time auths are one time! If someone finds my phone, or accesses one of my other net accounts that was authorized by my one time auth, they completely win until I can get back to google's page to revoke them. And related, I don't understand why the authenticator can't generate these one time passwords -- MANY TIMES THAT WOULD BE A LOT MORE CONVENIENT than having to go to the specific page on the web. And also related: why is there no pin or password for the authenticator? These are just questions I have -- I'd love to read a page or two that discusses these issues -- I think having a good model of how and why it works as it does would help me secure my data.
- modeless 15y agoThe reasons why the authenticator cannot generate Application Specific passwords and why it does not need a PIN lock are the same: the entire point of 2-factor authentication is that the authenticator by itself is not enough to gain access to your account. You must separately provide both a code from the authenticator and your real password every time you log in. There's no such thing as a "one time password". There are "Application Specific passwords" which work exactly like your regular password except that they limit access to critical account settings and can be created/disabled at will. If someone obtains one of your Application Specific passwords then they can use it to log in and access your data until you revoke that password but they cannot change your real password and deny you access to your own account.
- jerrya 15y ago"If someone obtains one of your Application Specific passwords then they can use it to log in and access your data until you revoke that password but they cannot change your real password and deny you access to your own account." Ah. I think this is the key I hadn't understood till now. Thank you.
- metageek 15y ago>There's no such thing as a "one time password". Some people call the code generated by the authenticator a one-time password, because it can't be reused.