Recent Features
| |||||||||||||
Google Authenticator for multi-factor authenticationGoogle Authenticator for multi-factor authenticationPosted Dec 8, 2011 0:28 UTC (Thu) by dwmw2 (subscriber, #2063)In reply to: Google Authenticator for multi-factor authentication by sfromm Parent article: Google Authenticator for multi-factor authentication
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.I have that working locally. See OpenSSH bug #983. 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 ☹
(Log in to post comments)
access to the shared secret Posted Dec 8, 2011 2:50 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
This is way, way, worse than the password case, because the password, even in /etc/passwd days, was stored as a salted CPU-intensive hash. So the bad guys have to do a bunch of heavy lifting (even today it's far from trivial to reverse those old DES based hashes for a decent 8 character password, and if the user upgraded to PHK-MD5 hashes and a 10 character password, kiss your chances goodbye).
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.
access to the shared secret Posted Dec 8, 2011 2:58 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] "This is way, way, worse "You are absolutely correct. I do apologise for understating the astounding stupidity of the default Google Authenticator setup.
access to the shared secret Posted Dec 8, 2011 13:50 UTC (Thu) by PlaguedByPenguins (subscriber, #3577) [Link]
how about using google authenticator (or yubikeys etc.) via radius - then you can put all the plaintext secrets on a "secure" radius machine that's heavily defended. no more secrets on clients.
Google Authenticator for multi-factor authentication Posted Dec 8, 2011 6:55 UTC (Thu) by Cato (subscriber, #7643) [Link]
Thanks for flagging this, that's truly a terrible design decision and makes me wonder about the rest of Google Authenticator.
Google Authenticator for multi-factor authentication Posted Dec 8, 2011 9:13 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] "Thanks for flagging this, that's truly a terrible design decision and makes me wonder about the rest of Google Authenticator."I'd fairly much reached that state as soon as I realised it was kept in Mercurial. The ~/.google_authenticator braindamage just served to confirm my prejudice ☺
Google Authenticator for multi-factor authentication Posted Dec 8, 2011 10:57 UTC (Thu) by drag (subscriber, #31333) [Link]
Call me stupid, but I don't really understand what is so horrible about ~/.google_authenticator. I really want to understand exactly why this is bad.
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?
Google Authenticator for multi-factor authentication Posted Dec 8, 2011 11:43 UTC (Thu) by drag (subscriber, #31333) [Link]
ok. I think I understand now. The ~/.google-authenticator is on the server-side and is what pam uses to authenticate your user.
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?
Google Authenticator for multi-factor authentication Posted Dec 8, 2011 13:12 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] Google Authenticator doesn't use public/private keys. It has a single symmetric key. Essentially there is no public key; only a private key.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.
|
|||||||||||||