Hacker News Reader

Comment by sweis | Hacker News Reader

Note that besides sending codes via SMS, Google's two-factor authentication also supports time-based one-time passcodes (TOTP) that can be generated from a mobile device. They also support a list of one-time printable codes. I kept a couple of copies of these in my wallet and at home.

TOTP is an open standard and the mobile app is open source:

http://tools.ietf.org/html/draft-mraihi-totp-timebased-03

http://code.google.com/p/google-authenticator/

(Disclaimer: I worked on this.)

View on HN

Looking at your links and the authenticator, is it the case that any third party web app can use the google authenticator "merely" by providing a key and account name?

Is anyone doing that?

I really like using the authenticator on my phone and would love to see other web applications support it.

But I am curious, why isn't the authenticator itself password protected?

Also, fyi, while I understand how to use application specific passwords, I have no good understanding of what they do, how they work, why they are safe or why I only have to enter them once. So they are confusing to me.

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.

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

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

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

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

Yes any application can use it. I currently use it as a requirement to log into my server via SSH.

However, you are using a PAM module that was developed by Google. I'm not sure if Google's Authenticator program has enough of an API to allow any program to implement 2-factor authentication using their program yet, but it could be possible.

Python code to validate via Google authenticator (sorry, self link): http://www.brool.com/index.php/using-google-authenticator-fo...

Cool. I hadn't taken a look at the PAM module personally, so I didn't know if the code was as tightly nit to that implementation as some other crypto code (I'm looking at you, scrypt).

Good to see it can be implemented outside of Google products.

If the program uses the same algorithm I don't see why not. Here is a module for Drupal that uses Google Authenticator: http://drupal.org/project/ga_login This seems to be the implementation it's using: http://code.google.com/p/ga4php/source/browse/trunk/lib/ga4p...

Edit: of course, this is just another implementation of the TOTP method. It does not use Google's infrastructure to send you SMS / voice calls containing the code.

I know this is way off topic, but "time-based one-time passcodes" mapping to the acronym "TOTP" bugs the heck out me. Why are the hyphenated terms not treated equally by the mapping? Argg... I'm going to be thinking about this for hours!

It's only weird if you think about it.

Reply on news.ycombinator.com