On Mon, 2011-10-17 at 19:02 -0700, Toshio Kuratomi 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.
And all of this is what I was describing, apparently poorly:
- the pam module lets us refer to that server via a web request with the
info the user is providing.
- so our server-side is just a cgi.
-sv