On 05/30/2012 12:13 PM, Dmitri Pal wrote:
On 05/30/2012 03:44 PM, Erinn Looney-Triggs wrote:
I have for a while had an interest in integrating Google's two factor auth (https://code.google.com/p/google-authenticator/) into my environment. However, the code Google gives is close but not there for a centralized auth setup.
Now there are other projects to deal with this like totp-cgi (https://github.com/mricon/totp-cgi) which relies on another PAM module (pam_url).
However, it seems to me that SSSD might be an appropriate place for something like this, so I wanted to gather some thoughts on the feasibility of integrating two factor auth into SSSD.
Let me lay out my idea here, and open it up to criticism.
Essentially Google authenticator uses a shared secret that is held both on the authenticating system and on the device (your cell phone). This shared secret then has a bit of magic run on it (https://tools.ietf.org/html/rfc6238) and if what the user enters and what is computed match, you are good to go.
It seems to me that it would be very easy to centrally store this shared secret (as well as some emergency codes that are generated in case you lose your phone) in LDAP then retrieve it using SSSD (thus allowing offline caching). The problem is that the shared secret is, well plain text, and sensitive, I don't know if there are ways to mitigate this or not. Is there a secure storage for something like this?
Second question is, would SSSD be an appropriate use of this, and if so, is it easy to work into the PAM stack to have this as a second prompt, e.g. Password: TOTP:
Let me know your thoughts, concerns, etc.
Here is what were thinking about:
https://fedorahosted.org/AuthHub/wiki/ArchitectureDiagrams https://fedorahosted.org/AuthHub/attachment/wiki/ArchitectureDiagrams/Diagra...
Replace PAM box on the diagram with SSSD and you will get the picture.
The benefit is that you get a kerberos ticket as a result of the 2FA.
Will this meet your needs?
Thanks Dmitri.
If I am understanding this correctly, the place then for a plugin and interface to the google auth shared secret would be on the KDC? Which at that point could call out to anywhere and do what it needs to do.
I assume the channel for passing information back would be encrypted and authenticated using kerberos from the client to the KDC?
Do you have any more docs or info on how this all is put together?
In short, yes it looks promising, thanks for the pointer.
-Erinn