On Mon, 17 Oct 2011, seth vidal wrote: > Hi all, > I've been reading and noodling around with some of the 2factor auth > (2fa) mechanisms available - trying to figure out which ones fit for our > users, our use case, and our mandate (open source ftw). > > OTP (TOTP or HOTP) appears to be the most common type. TOTP is what > google authenticate uses and is more or less what the rsa securids, etc > use. > > The biggest problem with OTP is that it's a symmetric key that both ends > have to know (in the clear) to generate or validate the password. This > means that if your server side gets compromised then everyone's keys are > immediately invalidated. > > The second problem is that you need some sort of device that can run > either an ios or an android app to generate the passwords from the > secrets. ( Curiously enough you don't really need that - you can use the > secret on your computer to make the passwords too using some really > simple code - especially the TOTP ones. However, at that point it is not > 'something you know and something you have (on another device that is > not connected to your computer) it is something you know and a piece of > software you run on your computer which, obviously, anyone who cracks > your computer can then use to login as you - but I digress) > > Yubikeys - which we are already using - not fabulously, is a combination > of an assortment of those. > > The biggest problems with the yubikeys is: > 1. getting them into people's hands > 2. getting another one into their hands when they lose or break the > last one. > 3. the company who makes them being relatively small and afaict the > only company who makes them. > 4. kinda fiddly. > > > > Now - we could just use the tools that google offers - which are open > source - at: http://code.google.com/p/google-authenticator/ > > but the problem there is that it requires storing all of the secrets on > any/every machine you would need to login to. Since the secrets in OTP > are clear and vulnerable it makes that an unacceptably high risk, imo, > to put them on all of our machines. > > So I started hunting around and I think I have some of a solution to > this part of the problem: > > Here's how it should work: > > - you go to login > - you're prompted to supply your normal/regular password + your > one-time-password(otp) (all on one line - which means not having to hope > that the apps can cope with this) > - you go to your phone or other ios/android device. Open the app that > gives you your otp and input that with your password. > - the login is passed to a pam module which relays this auth-attempt to > a cgi housed on our fas servers (or potentially in multiple locations > for network-dispersal) (the cgi runs over https, obviously - maybe > authenticated with client-side ssl cert?) > - the cgi checks the otp and replies 'yay, nay, or broken'. > - you are logged in or reprompted or whatever.; > > > linotp implements most of this -but they've added a lot of bits to it > that we probably don't need and their pam module looks to be about 90%+ > of what we do need. So that might be where we go from here. > > > > Now - how do we get people their otp secrets, etc: > That depends on who 'people' is - if people is really only people who > can sudo places then, imo, we do them all by hand - generating them (or > regenerating them) as we go. This is mainly b/c setting up too much > infrastructure to support this is just a fools errand if we're only > talking about 50-100 people to deal with and having a human in there > tends to make it harder to spoof. > > If 'people' is everyone who can commit to fedora then we've got to > figure out how to do it nicely: > one option could be something like: https://github.com/nathforge/pyotp > integrated into fas. > > Another option might be to send out OTP secrets encrypted to each user > using their gpg identity. > > > > > One final thing: Ricky Zhou mentioned this group: duosecurity.com. They > have a neat system and set of apps for smart phones/devices which > circumvent the problems with otp secrets being exposed. But it requires > that the device you have is connected to the internet in some way - > which is tricky, to say the least. Implementing something like their > system should be possible - but we're going to need someone who is an > android and/or ios app developer to help. > > > So - my questions are: > 1. Is requiring an android/ios device too onerous? > 2. Does the 'here's how it should work' section above make sense/seem > secure to everyone? > 3. who should we be requiring to use this? sysadmin-main? sysadmin-*, > anyone with a shell account? Would it make sense to make ssh keys + OTP > auth to get onto fedorapeople.org at all? what about fedorahosted? > > > need input. :) > Do we have any data wrt 1) ? I know I fit into that category a couple times over. Is there going to be an official "What if I don't have ios/android" plan? I see PYOTP has a library but it wasn't clear to me if it forces people to use the devices or if there was going to be some sort of soft solution alternative? Other then that it all seems sane, it would certainly work in my use case. -Mike _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
