2factor auth

[seth vidal]

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. :)

-sv