2factor auth

[Toshio Kuratomi]

On Mon, Oct 17, 2011 at 07:14:49PM -0700, Darren VanBuren wrote:
> We definitely would need to put the secrets on a higher security box,
> and even beyond that, we could look into encrypting the secrets as
> well, while contributing the patch back to upstream of course.
> 
I was thinking about that today.  We probably could encrypt the secrets
using the user's password.  Then whatever PAM module is used would need to
take the password before the otp and use it to decrypt th secrets.  Things
start to get dicey, though, when you think about what happens when the user
changes their password.  This would probably work as part of an integrated
solution (like FAS) but it's not a gneral purpose patch that could be sent
upstream without some, quite possibly deal-breaking, caveats as well.

-Toshkio

> Darren VanBuren
> ==================
> http://theoks.net/
> 
> 
> 
> On Mon, Oct 17, 2011 at 19:02, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > On Mon, Oct 17, 2011 at 08:26:37PM -0500, Jeffrey Oltlie wrote:
> >> On Mon, Oct 17, 2011 at 5:54 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> >> >
> >> > On the other hand google-authenticator doesn't have any server ability
> >> > yet. ;(
> >>
> >> I didn't think that google-authenticator needed a server to do the
> >> authentication - you just need the app on your phone and some
> >> configuration on the system that you want to access.
> >>
> > Correct.  But this is actually a bit of a drawback here.  We have a large
> > number of people coming into infrastructure who have various amounts of
> > access on the boxes.  We're constantly trying to balance security with the
> > need to keep entry barriers low enough for new contributors to get started.
> > With that in mind, there are many users who have an unprivileged shell on
> > boxes that, although we feel we know them well enough to give them that,
> > we've never met in person or have anything other than email/IRC
> > conversations to track who they really are.
> >
> > google-authenticator stores a shared secret in clear on every box that you
> > want to be able to auth on.  These secrets are protected by normal Unix
> > filesystem permissions but nothing else.  When evaluating this risk with how
> > much we don't know about our contributors, things begin to feel a little out
> > of balance wrt security.
> >
> > So what Kevin's getting at is that if we ran google authenticator, we'd need
> > to write a server for it so that we could keep those shared secrets on just
> > a few boxes with higher security, similarly to how yubikey and fas depend on
> > the database server and the three account system-dedicated app servers being
> > more secure.
> >
> > -Toshio
> >
> > _______________________________________________
> > infrastructure mailing list
> > infrastructure at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/infrastructure
> >
> _______________________________________________
> infrastructure mailing list
> infrastructure at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20111017/d6b2fa37/attachment.bin