libpam security model for SSH?

[ThomasHabets]

Original issue 4 created by w.romain on 2010-10-04T12:04:44.000Z:

The following is feedback/discussion and not a bug report.

Although google-authenticator seems primarily designed for Google Apps, I have been experimenting with it as a way to provide multi-factor authentication with SSH.

In case there is interest, I prepared some RPMs available at:
http://cern.ch/rwartel/google-authenticator/pam-google-authenticator-1.0-1.i386.rpm (built on a RHEL5 variant)
http://cern.ch/rwartel/google-authenticator/pam-google-authenticator-1.0-1.src.rpm
http://cern.ch/rwartel/google-authenticator/pam-google-authenticator-1.0.src.tgz
http://cern.ch/rwartel/google-authenticator/pam-google-authenticator-debuginfo-1.0-1.i386.rpm (built on a RHEL5 variant)
http://cern.ch/rwartel/google-authenticator/pam-google-authenticator.spec

The system works well and the client application is also very nice, but at this stage we have decided not to deploy it on our systems.

The main issue is the fact that the secret (used to generate OTP) is available in plain text in the home directory of users.

From our perspective, this seriously undermines the security model of google-authenticator for SSH authentication:

• In case the server is root compromised, the attacker may generate OTPs on behalf of any user. This issue is mitigated by the fact that users can choose to have a different secret per host, but this is outside of the control of the system administrator.
• When shared filesystems are used to host home directories (we use AFS), there is a significant possibility of cross-contamination should any of the hosts mounting the home directories be compromised.

The code could easily be modified to store the share secret in a location different from the home directories or from the server itself, for example by implementing a central service for storing the secrets (Yubikeys typically do this). However, ultimately, the issue is that the OTPs are generated based on a shared secret. Shared secrets are extremely difficult to protect and always result in additional risks to be managed.

This is of course inherent to RFC 4226, and I am surprised/curious that no other standard was chosen?
I assume you have considered using systems based on public/private keys, why were they excluded?

Other solutions seem to exist as well, for instance based on hashes, like RFC 1938/2289: "added security is provided by the property that no secret information need be stored on any system, including the server being protected."

Any feedback welcome!

[ThomasHabets]

Comment #1 originally posted by markus@google.com on 2011-03-09T20:03:32.000Z:

While I appreciate your comments, a lot of them are outside the scope of the libpam module.

So, I will go ahead and close this issue for now.

Having said that, for a large-scale distributed installation, your best bet is probably the use of a centralized authentication server. You would then forward all authentication requests to this trusted server and no state would ever be stored locally.

I suspect that you could re-use most of the code from pam-google-authenticator.c for use by your authentication server. If you require us to refactor the code to expose some of the internal API, please say so, and we'll consider doing that.

[ThomasHabets]

Comment #2 originally posted by gert@meanderrings.net on 2011-10-29T08:59:17.000Z:

What about storing the shared secret with a symmetric cypher based on a hash of the entered password? You might actually use a dedicated private/public key of the system to code en decode the shared secrets.