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.
Darren VanBuren
==================
http://theoks.net/
On Mon, Oct 17, 2011 at 19:02, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Mon, Oct 17, 2011 at 08:26:37PM -0500, Jeffrey Ollie wrote:
> On Mon, Oct 17, 2011 at 5:54 PM, Kevin Fenzi <kevin(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure