Open Bug 570252 Opened 14 years ago Updated 1 year ago

Provide Optional Two Factor Authentication Support for Selected Accounts

Categories

(Bugzilla :: User Accounts, enhancement)

Product:
Bugzilla
Component:
User Accounts
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

People

(Reporter: mcoates, Unassigned)

References

Details

(Whiteboard: [extension]) 

Power users within bugzilla have access to critical security related bug flaws for various products. In many organizations, Mozilla especially, it is desired to provide additional authentication controls around these accounts. Although IP address locking is currently in place, it would be great to provide support for two factor authentication via client certificates or a key fob.

This security enhancement could be enabled by a bugzilla system admin and then applied to specific accounts or groups. It doesn't make sense to apply two factor auth to all user, but the ability for an organization to selectively implement two factor auth is a great security enhancement.
Severity: normal → enhancement
  Okay, this would be a reasonable extension (probably wouldn't be part of Bugzilla core), but how do you support that sort of two-factor authentication via a web browser?
I think the client certificate would actually be a difficult solution since I'm not aware of anyway this could be user-specific.  I believe the client cert requirement would apply to all users or no users. So this idea is out.

For the key fob idea, we would probably have to build an extension for a specific vendor. For example we could support keyfobs from RSA (RSA SecurID).  We'd then work with them to understand the proper implementation.  However, at its basic level, the user will provide their keyfob random number during authentication, their username, and their password. Bugzilla would compare the username and password and then use a service to verify the SecureID number is valid for the user account. If everything is good then bugzilla allows the login.
PayPal allows for the use of VeriSign's Identity Protection (VIP) for two-factor authentication. Might be worth looking into.

https://vipdeveloper.verisign.com/vip/
Michael: Actually, I think client certs would be the *only* way to do this. Are you suggesting that we require some sort of browser plugin to do authentication?
Whiteboard: [extension]
Nope, I'm not suggesting a browser plugin.  I used the term "extension" in comment 2 in reference to a bugzilla extensions (as you mentioned in comment 1).  

The RSA SecureID (http://www.rsa.com/node.aspx?id=1156) or the VerSign idea suggested by Reed would both just require changes to bugzilla's authentication routines.  The link provided in comment 3 provides demo code we can play with. We would use the first option - Authentication Service.

The problem I foresee with client certs is that they are requested during SSL setup, so there is really no application logic at this point. As a result, any user wishing to connect to the bugzilla website would need a valid cert. This does not allow an admin to selectively apply the 2-factor auth requirement on particular users. It would be an all or nothing decision.
  Okay. I think that details about the client cert might be accessible via the CGI environment, though. Not sure--never tried to use one with Apache. But if we can use the RSA/VeriSign stuff without a browser plugin, that could work too.
> Okay. I think that details about the client cert might be accessible via the
> CGI environment, though. Not sure--never tried to use one with Apache.

for what it's worth, with apache it's possible, but disabled by default.
it's the ExportCertData option for mod_ssl.
Starting to poke around with this... for RSA SecurID, there's a Authen-ACE4 perl module that we can use.
How about this?
http://motp.sourceforge.net/

Requires nothing other than MD5 on the server (the perl implementation of the checker is 20 lines in the reference impl, which can certainly be improved), and there are clients for most mobile phones.
http://motp.sourceforge.net/motp_in_perl.txt

We'd need a way of getting people to submit their init_secrets, but that would be arguably as much hassle as purchasing and mailing out SecurID tokens to all those people. And it has the great advantage of being all free software.

Gerv
I would want to further investigate why it is using MD5. The algorithm is generally regarded as broken, but that's not necessarily true in all cases. However, most people avoid MD5 all together instead of trying to figure out if there use case of it is at risk due to MD5 weaknesses.
random idea: how about using OpenID as the authentication mechanism within bugzilla, and have key staff use a mozilla-provided OpenID server which uses client certs to auth?
mcoates: I assume MD5 is used because MobileOTP was created quite some time ago. We could certainly imagine reimplementing it using another hashing algorithm, but unless we could persuade all the mobile clients to support it, we'd lose a lot of the benefits.

Of course, this is something they should probably do anyway. The question is whether we make it a blocker for us ever rolling it out.

I'll make enquiries.

Gerv
I got the following back from the MobileOTP guy <matthias.straub@gmail.com>:

Hi Gerv,

Thanks for your interest in Mobile-OTP, it is very much appreciated. I
hope that I will be able to resolve your concerns about the security
of the algorithm. That said, any cryptographic hash would do for
Mobile-OTP in general.
Changing the hash now or even introducing flexibility would be
problematic, though, as there already are more than 30 independent
Mobile-OTP implementations, all obviously based on MD5.

When I came up with the algorithm in 2003 I chose MD5 because it was
readily available on different platforms. I chose MD5 even though I
was aware of the security concerns. The reason for this is, that the
known MD5 vulnerabilities have no relevance for OTP algorithms. MD5
generates a 128 bit hash, but we are only feeding it between 78 and
142 bits of data (64 or 128 bit secret plus 14 bit PIN). The odds of
an MD5 collision within this small amount of data are practically zero
and are not higher than with any other alternative cryptographic hash
algorithm.
The security flaws of MD5 are only relevant for larger amounts of
hashed data - as only larger amounts of data will provide room for
collisions.

To summarize, Mobile-OTP would not be more secure with any different
hash algorithm, but is more dependent on choosing a 16 or 32 character
secret (64 or 128 bits). I estimate that brute-forcing 64 bits would
still be a challenge for the NSA while brute-forcing 128 bits is in
fact impossible. Many Mobile-OTP implementations allow to set a 32
character secret, while I consider 16 characters to be safe enough.

I any case, an attacker would have to be able to get access to one or
more one-time-passwords to even try a brute-force attack.

If your security policy at Mozilla forbids the use of MD5 in
principle, it would not be too difficult to replace MD5 by SHA2 for
the implementations you need. I would also be happy to support you
with this (although I consider this step to be unnecessary). Please
feel free to contact me.

Best regards,

Matthias
So yeah, this is implemented on bmo now (bug 1196628 - not quite done yet, but live and usable and they're cleaning up loose ends now).

It would be awesome to get it ported upstream. :-)
You need to log in before you can comment on or make changes to this bug.