On 02/01/2011 12:02 PM, Marsh Ray wrote: > On 02/01/2011 10:56 AM, Gervase Markham wrote: >> Dear crypto-hackers, >> >> Your thoughts on the following problem would be appreciated. >> >> Goal: fix bug 570252. Provide 2-factor authentication for some Bugzilla >> accounts. >> https://bugzilla.mozilla.org/show_bug.cgi?id=570252 >> >> Sub-goal: do it in a way which doesn't involve purchasing or running >> proprietary software. >> >> General musings on these goals welcome. Here also are some specific >> questions: >> >> Q1) There is conflicting advice in that bug about whether a client >> certificate-based solution > > Whether or not client certs count as a second factor is somewhat > philosophical. In some sense, the private key stored in the browser > functions as another "something you know" like a password. If the PC > is pwned, they can get the private key too. > > Of course, just about anything is better than just a password alone. You are presuming generic certificates. Certificate auth can be part of a 2 factor system if stored in a token. You can know the cert is stored in the token if you issued the certificate and you know you only issue certificates into tokens. > >> can meet the requirement of "implement it >> only for some accounts" (with the implicit requirement that it doesn't >> bother or affect people who are not using it). Can a client certificate >> solution be made to work? > > Those accounts would probably have to access a particular URL and be > banned from the main one. May or may not be an issue. There are lots of ways to meet this requirement, though some may require tweaking of server code.
1) use request/not require certificate. If a certificate is supplied, that will show up in the initial handshake. The certificate will tell the server which account and you can bypass login altogether. If no certificate is supplied, you can bounce to user to a normal login screen. The server would have to know if some accounts must have certificates or not. Downside: This doesn't work well with 'remember these settings' options -- particularly IE's version-- there is no way to tell the browser to 'unremember' the setting. I think IE will prompt for the certificate even if there isn't one you can use. Netscape/Mozilla family browsers will usually not supply the certificate if there isn't one available, nor will it prompt the user, but if the user has a certificate that doesn't (even if it doesn't match the ca list from the server), it may be that Firefox prompts for it (I don't know what the current semantic is). Back when ask automatically was the default, this could be made to work really smoothly with smart cards (including automatically changing state when the smart card was inserted or removed. 1) use normal ssl on your opening page. When the user logs in, if the account requires a certificate and SSL-Renegotiate is initiated. This can be accomplished as Marsh indicates by bouncing to a different URL, but it's possible that you can create a server that handles this directly. This may be what Marsh was thinking since he was instrumental in discovering the original bug in SSL-Renegotiate and also in pushing to get is resolved. Downside: The user needs to start the login process before you know that you need a new cert. This only works safely with newer browsers (which has the renegotiate extension). Obviously you server needs to properly handle the extension (including refusing to renegotiate with clients that don't have the extension). > >> Q2) If not, does anyone know of any commercial 2-factor systems which >> can be implemented entirely with open source tools and software? (I'd >> accept having to purchase closed hardware tokens.) If you want an open source solution, you can look at Dogtag with it's Token Management System. It even allows secure provisioning remotely (mail an unpersonalized token to remotee, The plug the token in and TMS will load the token with the appropriate keys and certs after validating the user with the mechanism of your choice. I
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
