Comment #1 originally posted by markus@google.com on 2011-03-18T10:35:21.000Z:

Not sure whether we want to do this.

LDAP is a relatively complicated protocol that we probably don't want to reimplement ourselves. On the other hand, linking against existing libraries is difficult to do correctly in PAM modules. A PAM module must not have any dependencies on external libraries nor must it export any symbols other than the ones specified by the PAM API.

Furthermore, LDAP isn't necessarily the best protocol anyway. We have to make sure that untrusted parties never get hold of the secret. And this is challenging to do with LDAP.

Finally, features like rate-limiting should really be centralized. So, running one instance of the PAM module per client is not quite ideal.

For users who need centralized administration of secrets, it might make more sense to provide an authentication server that speaks a very simple challenge/response network protocol. Clients could then have PAM modules that interface with this authentication server.

Providing an authentication server is not incredibly difficult. But is also somewhat outside of the scope of this project. We might eventually provide sample code to do so, but it is not a particularly high priority.

Comment #2 originally posted by markus@google.com on 2011-08-02T15:38:43.000Z:

Issue 90 has been merged into this issue.

Comment #3 originally posted by charly.rohart on 2011-08-08T14:01:33.000Z:

For those who need to use the Google Authenticator with LDAP users (with seeds encrypted in LDAP) you can use the OpenOTP server.
There is a PAM lib (with network challenge-response protocol), RADIUS for integration of GA with VPNs, SOAP/JSON interfaces to integrate in web apps, and GA OpenID idp.

It is completely free (below 25 active users) so don't hesitate to use.
We love the GA and also built this full-blown server software with deep integration of GA (including self-service desk, etc).

My congratulations to the GA developer team for the very good work ;-)

Comment #4 originally posted by jeff@crowdstrike.com on 2011-11-10T00:36:00.000Z:

Is it possible to deploy google-authenticator as a PAM module on FreeRADIUS for one-time-passwords without any additional coding?

I'm trying to figure out if I can plug this into FreeRADIUS and point my Cisco ASA at the Radius server in order to have each user use OTP for authentication.

Comment #5 originally posted by jeff80 on 2011-11-10T00:40:19.000Z:

Is it possible to deploy google-authenticator as a PAM module on FreeRADIUS for one-time-passwords without any additional coding?

I'm trying to figure out if I can plug this into FreeRADIUS and point my Cisco ASA at the Radius server in order to have each user use OTP for authentication.

Comment #6 originally posted by srhuston on 2011-12-07T16:05:07.000Z:

I just had a similar thought. I can understand the feeling that this might be outside the scope of the project, but let me expound a little.

With the secret saved in the home directory, a local root exploit would mean all the secrets are instantly considered compromised. Even if root squashing is setup as in the systems I maintain, a quick 'su' to each account in turn and reading the file will gather them all before you can put a stop to it (yes, AFS or other encrypted filesystems would solve that too).

On the other hand, storing the secret for each account in an LDAP attribute attached to that user's record would mean that LDAP securely holds the keys. Set the attribute only viewable to the user after they're bound, and the system must then bind to LDAP using the user's password to read the secret - since I believe the PAM gets the entered password on login, it should be "simple" enough for it to bind to LDAP to read the secret with the given password. This would mean that to retrieve all the secrets, either an LDAP administration account or every user's password would need to be compromised, which is much less likely than a local root exploit reading from the filesystem.

OTPs could be used as well with another attribute-key pair, and just as in the local file that has each OTP removed as it's used the attribute could be removed from the LDAP record after it's been used (slightly more complex if multiple values are entered with the same attribute name, since one must read them all in, delete them all, then write them back to the record; not impossible, but just not as simple as 'delete this value'). Again, these values could be set in the schema to only be readable by the user once bound to the directory.

Comment #7 originally posted by brian.ristuccia on 2012-08-14T21:07:29.000Z:

Storing plain text seeds in LDAP is a bad idea. Even if the seeds are only accessible by bound users, someone with local root on a system can gather passwords and seeds for every account that logs in there. A better idea is to use google_authenticator_pam as a backend for your favorite auth server. This method "just works" with the existing code and keeps the seeds inaccessible from untrusted client machines.

Of course plain text seeds are still at risk if the auth server gets owned, but it's hard to mitigate that problem without adding some sort of HSM support to google_authenticator_pam.

Comment #8 originally posted by tmackey@evernote.com on 2013-06-04T22:05:17.000Z:

You don't need root. Note that storing a totp secret in a user's account where the user can bind and read it with their own password defeats that secret and the basic premise of 2-factor in general.... anyone that has or can change the user's password can then simply bind to LDAP and view the secret and start generating their own codes.

To do this securely you have to store the secret encrypted, and write ACLs that prevent the user from seeing even the encrypted values. The authentication method would use an account that can read the secret, decrypt it and perform the TOTP verification.

Fwiw http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=e069a79239774e4fb1a68358c37ab79c0afd0e2d

All of the official OpenLDAP admin docs already advise to set ACLs preventing read access to userPassword attributes. In a typical install no users ever have read access to their own password (or anyone else's).

This issue was moved to google/google-authenticator-libpam#43