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:
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:
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?
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!
The text was updated successfully, but these errors were encountered:
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.