Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Google Authenticator for multi-factor authentication
Posted Dec 7, 2011 23:49 UTC (Wed) by smoogen (subscriber, #97)
Posted Dec 8, 2011 0:28 UTC (Thu) by dwmw2 (subscriber, #2063)
It appears you can't use google-authenticator with one's SSH key, which is unfortunate. I would like this a lot better if I could do OTP and still use my SSH key.
You really also want to fix GA bug #51 if you want to use Google Authenticator for real. Storing the key in ~/.google_authenticator, so that any code running as your user can read or change it, is entirely stupid. Imagine if your system password was stored in ~/.passwd instead of /etc/shadow where you can't even read it!
Unfortunately, this involves patches to two of the least responsive upstream projects I've ever had to deal with ☹
access to the shared secret
Posted Dec 8, 2011 2:50 UTC (Thu) by tialaramex (subscriber, #21167)
But with these OTP systems the stored value is a shared secret. If the bad guy has it, they can successfully authenticate as you with no additional work.
Posted Dec 8, 2011 2:58 UTC (Thu) by dwmw2 (subscriber, #2063)
"This is way, way, worse
Posted Dec 8, 2011 13:50 UTC (Thu) by PlaguedByPenguins (subscriber, #3577)
Posted Dec 8, 2011 6:55 UTC (Thu) by Cato (subscriber, #7643)
Posted Dec 8, 2011 9:13 UTC (Thu) by dwmw2 (subscriber, #2063)
"Thanks for flagging this, that's truly a terrible design decision and makes me wonder about the rest of Google Authenticator."
Posted Dec 8, 2011 10:57 UTC (Thu) by drag (subscriber, #31333)
When I am using Kerberos, for example, the ticket cache is stored in something like /tmp/krb5cc_1000. Anybody who has access to my account can read and use those tickets to get access to any service I have access to. These are stored under 700 and are rw by my users. Kerberos can be two-factor if I a service asks for a password in addition to the ticket from the ticket granting service. The 8 hour expiring of the ticket provides plenty of opportunity for mischief.
When I am using OpenSSH, again my keys are stored in ~/.ssh/ and is read/writable by my user. Openssh keys are legit and commonly used two-factor authentication since I need both the keys and the password to decrypt them.
How is ~/.google_autheniticator worse?
Even if I have a hardware dongle or a physical RSAkey-style OTP password then if somebody has access to my account they have access to the hardware key or any OTP key I type into the system just as much as I do. If somebody has access to your account on your PC that your using then it doesn't matter what sort of authentication system your using, your screwed anyways.
Is there something I am missing here?
Posted Dec 8, 2011 11:43 UTC (Thu) by drag (subscriber, #31333)
I thought it was part of what you needed on the client side. My mistake.
In this case it's not like kerberos tickets or private ssh key at all. It's more like the public key for SSH RSA/DSA authentication.
Even then it's not horrible or stupid, I think. It seems obvious that ~/.google-authenticator file is intended for the user to setup for themselves without administrative help in addition to passwords. So in that case it makes sense that it's in the home directory.
Is there a mode for the administrator to setup the secrets without user intervention; without the ~/.google-authenticator file?
Posted Dec 8, 2011 13:12 UTC (Thu) by dwmw2 (subscriber, #2063)
So no, the problematic part is not that it's like the SSH public key. The problematic part is that it's like keeping your SSH private key lying around on the file system without a passphrase.
And yes, the patch I mention above will allow you to keep the files in a root-owned and root-only-readable location.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds