2factor auth
seth vidal
skvidal at fedoraproject.org
Tue Oct 18 04:35:52 UTC 2011
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
More information about the infrastructure
mailing list