Re: 2factor auth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2011-10-17 at 16:54 -0600, Kevin Fenzi wrote:
> So, there's a lot of data here and info to process. ;) 
> 
> Some things (in no particular order): 
> 
> I think we have the following groups to consider: 
> 
> 1. Sysadmin-main folks who can sudo and login to everything. 
> (small. ~10-20)
> 2. Sysadmin* folks who can login to some things and sudo on some things
> (a number of small groups, total ~120ish ). 
> 3. packagers ( larger group, ~1100 ish).
> 4. cla+1group, fedorapeople, etc (larger yet, ~2500). 
> 5. web application users (testers, election voters, account sys,
> mirrormanager). ( larger group still)
> 
> I think the amount of hassle people will put up with increases as we go
> down the list, but also the amount of sensitive access decreases. I'm
> not sure we will have much luck pushing things down past the first few
> groups unless we make it VERY easy to use and manage and make sure
> there are no costs. 

I agree with that assessment except I think you meant 'decreases' not
increases in the first clause of your paragraph above.



> Does the yubikey OATH mode work with linotp/googleauth? 
> From what I can see it should. So, perhaps we can support both?

I think it should be possible - it will require some effort. Also it
will increase the complexity of what we have to support.


> I'm a bit leary of linotp having a 'community' and 'enterprise'
> edition, and some of the features in the enterprise we would need to
> re-implement.

1. we don't need to use linotp AT all - I wasn't suggesting we should
use it.

2. the part of linotp that is useful is their pam module and how it
works.


> On the other hand google-authenticator doesn't have any server ability
> yet. ;(  I did notice this stalled review: 
> https://bugzilla.redhat.com/show_bug.cgi?id=538327
> for otpd that might be worth looking at. 

That's what I was talking about - linotp's pam module gets us to the
point where we can talk to a server for validating the otps.


> Ideally, I'd love to see a solution like the duo-security one, but of
> course opensource and where we run all the parts of it (not a 3rd
> party). 

Duosecurity's mechanism will REQUIRE an internet-connected android or
ios device. There is no way around that. If we mandate that as required
then we can pursue an entirely different route. Also - there is nothing
in what I'm suggesting here that precludes us from pursuing that route -
it is just a fair amount more work b/c of the phone app [re]writing
that's necessary.


> 
> I sure wonder if other open source groups would be interested in
> getting something together, since I think a lot of them have similar
> groups to handle. 

on the one hand - sure - I suspect they will

on the otherhand - any effort to do that will be an enormous ass pain to
coordinate. If we wanted to pursue such a thing I'd want to start by
having something working to bring to a group of people and letting it
get refined by normal processes. Not starting with an idea and going
from there.

My current plan is to test out pam_linotp and see if I can make it work
w/a different cgi on the backend. If I can then I can see about grafting
a working tool together as a starting point.

Ideally one that can accept otp from google-authenticator AND (if I can
find the damn tools) yubikey auths.


-sv


_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure


[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux