Hacker News Reader

Comment by pejoculant | Hacker News Reader

Pretty cool. Google authenticator is another alternative that be used via a pam module, with the additional benefit that it doesn't need to connect to something else for verification.

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

View on HN

Seconding the recommendation for PAM/Google Authenticator.

Off-topic: Has anyone ever managed to get PAM/Google Authenticator working with RADIUS? I spent a while messing about with this last year, and never got it working exactly as I had hoped. I'm no longer working with RADIUS, but this post reminded me I never finished scratching that geeky itch.

I wrote a Sinatra app to act as a Google Authenticator backend for our FreeRADIUS instance as well as our web SSO. It also handles enrollment via generating QR codes:

http://it.isevil.org/blog/2011/11/13/authentication-service-...

Code: https://github.com/bithive/example-totp-vault

For FreeRADIUS we use rlm_perl to define our own authenticate() method; it just calls the web service to validate the codes.

Neat solution, thanks for sharing.

I can't speak for Google Authenticator but Duo works great with RADIUS http://www.duosecurity.com/docs/radius

I've been using Duo Security for two factor auth and have been very happy with it (also easy to set up). Free for all open source projects.

the problem is that google authenticator stores the seed in the phone(and the server) so if you lose it basically you lose the server too, right?

I think it still requires your normal password as well, so the server wouldn't be lost unless someone had both.

It's two-factor authentication: something you have (phone) and something you know (password to your ssh cert). So, you have to lose both in order to lose the server.

I don't think this is the case. Losing either loses the server in the sense that you won't be able to access it. The fix is that the "something you have" is both your phone and emergency codes.

In security, losing the server doesn't mean losing access to the server. Losing the server means that someone else has access to the server, as in an adversary.

Yes, if you lose either factor, you can't access the server. This is why with Google Authenticator you also get a one time pad with emergency codes. However, I don't know how well this would work with two-factor SSH... you'd need a separate one time pad for each server. And I'm not sure how the Google PAM module handles emergency codes.

No, both authentication factors are required, so either losing your phone or forgetting your password would be sufficient to lock you out. However, the Google authenticator PAM plugin provides emergency access codes to use in the case that the one-time password generator is not available.

If you mean lose access to the server, then the google-authenticator sets you up with a few emergency one-time codes you could write down on a note and keep safe, in case your phone is lost.

Not to mention you can write down the seed itself and simply type it into another phone.

I don't think google-authenticator does that, I think Gmail does that.

There's a bunch of references to scratch codes in the pam google-authenticator module, but I haven't actually tried to run the code.

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

If you are talking about not being able to log into the server anymore, you can make backups of the seed. On android, you just need to pull the file "/data/data/com.google.android.apps.authenticator2/databases/databases" off the phone.

This only works if your phone has been rooted.

the problem is that google authenticator stores the seed in the phone(and the server) so if you lose it basically you lose the server too, right?

If you lose your phone and your scratch codes, you've only lost access via SSH. So it's an inconvenience, but one you can overcome with the right setup.

Well, if that were the case, when I lose my phone (sadly, not if), I would be locked out of years of Google account data. Fortunately there are backup codes. (And for Google a phone number call/text recovery path).

Reply on news.ycombinator.com