On Fri, Sep 26, 2014 at 12:33 AM, Matt Palmer <mpal...@hezmatt.org> wrote: > On Thu, Sep 25, 2014 at 01:29:04PM +0100, Gervase Markham wrote: >> A question which occurred to me, and I thought I'd put before an >> audience of the wise: >> >> * What advantages, if any, do client certs have over number-sequence >> widgets such as e.g. the HSBC Secure Key, used with SSL? >> >> http://www.hsbc.co.uk/1/2/customer-support/online-banking-security/secure-key
I can see one advantage: * A client cert that's *not* on an external token is just bits on your device and doesn't add a physical thing you have to carry around. >> It seems like they have numerous disadvantages (some subjective): >> >> * Client certs can be invisibly stolen if a machine is compromised > > Well, the cert is quasi-public information, so it doesn't matter if they get > stolen, invisibly or otherwise. The private key, on the other hand... > <grin> But at any rate, just stick the key/cert in a USB HSM. Problem > solved. On a more serious note, putting the private key on a USB device or a smart card isn't a realistic solution. It's not even a "now you have two problems" kind of solution. If you do that, you have way more than two problems. I live in a country with a failed but still zombied initiative to issue client certs on smart cards to all citizens (or maybe residents; I'm not quite sure; I believe the issuance never reached more than 10% of the population anyway because for many people it makes more sense to have a driver's license for domestic use and to have a passport for global use than to have an ID card for EU use [the certs are on ID cards] and only a handful of people ever had hardware and drivers to use the issued certs) and I've worked in a project that was supposed to use these things for user login. The initiative is an expensive boondoggle that's a big waste of tax money. With desktops, there's the problem of having to obtain a card slot [not a problem with a direct USB device you mention], driver problems and usability problems. With non-desktops, there's the problem of not even theoretically having suitable hardware interfaces. Sure, it would be fair to say that the initiative in Finland was just badly executed: It occured to the government CA to file https://bugzilla.mozilla.org/show_bug.cgi?id=463989 only in 2008, even though the lack of root program inclusion was a major usability problem already in 2003 when I worked in a project that was supposed to use this stuff. And they've failed to follow up on that bug for 6 years now! Even if you point to e.g. Estonia for better execution, observation at a point in time is not enough. Compare with the South Korea ActiveX bank crypto, which might have looked like a good idea to some at some earlier point in time. Also, committing a large population to particular hardware interfaces for the token inherently risks obstructing progress. Paper-based one-time passcodes FTW! (That's how identifying people for government Web sites actually works in Finland--with banks acting as IdPs.) Now, you may say that tokens work on the scale of your company and of course they don't scale on the level of a country, but Gerv's case of a large bank in the UK is on the same level of scale as the population of a less populous European country. >> * Client certs are harder to manage and reason about for an average >> person > > Hmm... I think this one could go either way. If you get a cert/key on a USB > stick, is that massively different from the consumer's perspective from > getting a Yubikey or number-sequence token? A USB HSM and a Yubikey are massively different from each other, because the latter acts as a USB keyboard and, therefore, doesn't require special drivers or any sort of infrastructure work to integrate with a browser. >> * Client certs generally expire and need replacing, with no warning > > As has been noted elsewhere, that's a UI problem, and number-sequence tokens > aren't immune either. The UI problems with client certs are on a completely different level of problem than the UI problems with having to type four to six digits that you look up from a paper sheet or a small hardware widget. (Paper sheets FTW, BTW. More eco-friendly than hardware widgets. Don't break when bent or exposed to cold weather. Paper is easier to clone, yes, but that's not enough of a Real Problem to deserve solving. Usually, the problem isn't cloning but losing the original paper/widget.) >> * Client certs are either single-machine, or need a probably-complex >> copying process > > Or a USB HSM. (I'm starting to see a pattern here) How do you plug that USB HSM into a tablet with no USB host capability? (I'm saying "tablet" rather than "phone" so that you can't go "Well, with mobile devices, you just put the private key on the SIM.") All in all, paper sheet of one-time passcodes entered by hand to a form submitted over https work well, are time-proven to work before and after revolutions like smart phones and are platform-independent. Just say "no" to client certs and especially ones embedded on hardware tokens for bank use. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
