2factor auth

Toshio Kuratomi a.badger at gmail.com
Wed Oct 19 14:18:34 UTC 2011


On Wed, Oct 19, 2011 at 09:43:02AM -0400, Stephen Gallagher wrote:
> On Tue, 2011-10-18 at 15:36 -0700, Toshio Kuratomi wrote:
> > 
> > Once question that popped into my mind right now is will we have the ability
> > to specify that different groups and different users have different
> > requirements/access methods?
> > 
> 
> We've been talking about how to handle this. We haven't really touched
> on the idea of requiring a different level of assurance for different
> applications, but we are aware of the "lost token" problem.
> 
Note -- not just per-application.  Also per-user and per-group.
sysadmin-main might be required to use 2 factors to authenticate.  The
other groups have more possibilities -- would we require two-factors if they
have a second factor registered?  Would we require just the non-password
factor?  Would we allow either the factor?  In any case, we would have to
allow password-only if the user in question did not have a second credential
registered while we would likely need to allow (or mandate) two-factor for
the same application if the user did have a second credential registered.

If we move away from pure-ssh keys to login to hosts, pkgs.fedoraproject.org
and fedorahosted.org would be very interesting environments in this regard
as they need people from groups that we'd mandate to have two-factor and
groups that we wouldn't mandate to have two factor to login.  Currently, we
use ssh keys to login and ssl certs for authn to upload to the lookaside
cache.  If we stick with that, that may be easier as then we'd only be
changing auth for sudo.

> The current plan is for us to store an attribute with the user's
> challenge requirements in the user's LDAP entry (with appropriate ACLs
> to make it difficult for an attacker to learn). Right now we only have
> plans for a single method, but if you think that method->application
> mappings are necessary, please speak up (and preferably help propose a
> mechanism to store that information in LDAP).
> 
So here's where I tell you that ricky and mmcgrath were the two people who
worked on fas2 when they thought they could base it on LDAP.  I only came
into the picture when they decided it couldn't be made to work with LDAP and
needed to use a database instead.  In other words, currently, we don't have
any LDAP programming expertise on the infrastructure team.  So we're
unlikely to be any help to you :-(

> As for "lost token", the idea would be that the admin would be able to
> reset the user's login requirements to password or similar until a new
> token can be mailed out. (Leaving it up to the admin to perform proper
> verification that the token was actually lost vs. a social-engineering
> attempt).

So we might want to allow some of that to be done without admin
intervention.  As I say, we do not have the ability to do proper
verification over the majority of our account holders.  With that in mind,
we have two choices -- refuse them access, so they have to create a new
account or allow them to change token with minimal verification.  If the
latter, then there's no need for admin's to be involved.

-Toshio
-------------- 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/20111019/da0b10ad/attachment.bin 


More information about the infrastructure mailing list