Re: Client certs
Phillip Hallam-Baker wrote: > Going back to this thread because nobody seems to have addressed the > real issue - usability. And no one addressed another real issue: Bad software quality - especially regarding error handling. If something goes wrong at TLS level (maybe with or without client certs) you cannot simply reset its TLS state. You have to restart the browser. This is only one minor detail why client certs are not used. Ciao, Michael. (currently playing around again with a PKI product which uses client certs and crypto token) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
A relevant point here is that one of the main reasons for the difficulty in using client certs was a preposterous patent claim to the implementation of RSA in a hardware device with a USB serial interface. I kid you not. That might not be as much of an issue these days. The patent might have expired and even if it hasn't a sequence of recent SCOTUS rulings have made those sorts of claims difficult to support. But then again, since USB tokens are being replaced by smart phones anyway, perhaps even that is irrelevant. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
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 > > It seems like they have numerous disadvantages (some subjective): > > * Client certs can be invisibly stolen if a machine is compromised > * Client certs are harder to manage and reason about for an average > person > * Client certs generally expire and need replacing, with no warning > * Client certs are either single-machine, or need a probably-complex > copying process > > What are the advantages? With client certs you don't need online access to a server backend infrastructure like for all the OTP mechs. Revocation checks can be done with simple CRLs. So it's far easier at the server's side. Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Am 2014-09-25 um 14:29 schrieb Gervase Markham: > What are the advantages? One-time passwords can be phished, certs can't. Kind regards, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention "FROM NG" in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 06/10/14 14:13, Phillip Hallam-Baker wrote: > I have the configurator running for Windows Live Mail and I will add > outlook soon. But I abandoned the attempt to do T-bird because I just > can't get the dev system running on my Windows box despite more than a > day trying. The documentation is incomplete and misses out references > to necessary tools to even build the library. That sounds unfortunate. Do contact the TB team or file a bug on the documentation, please :-) > The error made in T-bird is that it ignores the fact that storing keys > is a platform concern. Platforms such as Windows and OSX have code and > in many cases hardware to protect keys. Applications should use them. See https://bugzilla.mozilla.org/show_bug.cgi?id=432802 for some background here. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On Thu, Sep 25, 2014 at 8:29 AM, 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 > > It seems like they have numerous disadvantages (some subjective): > > * Client certs can be invisibly stolen if a machine is compromised > * Client certs are harder to manage and reason about for an average > person > * Client certs generally expire and need replacing, with no warning > * Client certs are either single-machine, or need a probably-complex > copying process > > What are the advantages? Going back to this thread because nobody seems to have addressed the real issue - usability. Right now I am working on email encryption but solving the usability issues of email requires a general solution so I have worked on these issues as well. And I think I have solved them. Passwords have terrible security because they shift the cost to someone who does not care about security of the asset because they don't own it. I use the same password for my Washington Post, New York Times, Slashdot, etc. accounts and it was leaked over five years ago. I do not care because it isn't my asset involved. So the passwords get forgotten and no password is better than the security of the recovery system which is SMTP. Passwords are also horribly insecure because they are disclosed to validate them. Now we could solve this with some clever crypto scheme but why bother when its actually easier to design a sensible PKI scheme. Passwords also have pretty horrid usability. But they get away with it because implementation of client certificates is really, really bad. One time tokens are pretty horrid usability as well. You have to carry the thing about with you. Which I won't do unless I am paid. So most of those schemes are migrating into smart phones. TAAA-DAAA! We are now emulating 1970s technology with a computer that would have been supercomputer class in the 1990s. There is a much better way to use a smartphone, send it a message that asks "Do you want to pay your gas bill of $503.43?" and have the user answer yes or no and the app return a signed message. I am currently working on making S/MIME and PGP email really really easy to use. As in no more effort to use than regular email. As part of that I have written a tool that creates and installs a certificate. For a self signed cert the process is just run the configurator tool and its done. For a CA issued cert, the user will specify the domain name of the CA and it is done. Not even email links to click on because the configurator has control of their mail app and can do the challenge/response automatically. [There are other validation schemes supported but I won't go into them here] What I have taken out is all the makework that the user currently has to suffer. And this is not just bad for Thunderbird, it is poke the user in the eye with a sharp stick bad. It literally takes a quarter of an hour to go through all the incantations. And that is me doing it, I know what I am doing. I would expect no more than 60% of users to follow instructions correctly. And all the effort is complete makework. The user has to pull the certificate out of the Windows store and install it in T-bird. Oh and repeat once a year. Client SSL certs are just as bad and in addition the use interface is horrid like it is on every other browser. The basic problem with most Internet crypto is that the implementation is 'enterprise grade'. By which I mean terrible usability because the person who decides what stuff to buy will never use it. The problems don't require a usability lab to sort out either. In fact DON'T go to the lab. If the user is being given work to do then the design is wrong. I don't need to test out my configurator in the usability lab because there isn't a user interface to test. OK so how do we solve the usability issues Gerv raised? * Certs expire after 1 year * Transferring keys between devices? Answer: We don't. Look again at the requirements. What are the use cases that drive them? I can't see any driver for enterprise or consumer deployments. I can't even see a need to do either in the government case, but the first is probably inherited from NSA doctrine. First step to sanity is that authentication keys are only ever in one machine. If a user has two machines then they have two keys. If they have eight machines then they have eight keys. This solves two problems, first the key transport problem, second a large chunk of the revocation problem. If a device is lost we only need to affect one device, not every device. [Decryption keys are another matter, there are good reasons to have a single decryption key in multiple devices. And the reason that I got into the per device authentication keys
Re: Client certs
On Fri, Sep 26, 2014 at 1:09 PM, Ryan Sleevi wrote: > There is so much usability failure in smart cards that I've > worked quite hard to keep them out of scope of W3C Web Crypto WG Thank you. > (which, > unfortunately, looks like that may fail in the rechartering and all hell > will break lose). Is there anything that can be done to help avoid all hell breaking loose here? -- 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
Re: Client certs
On Tue, September 30, 2014 5:47 pm, fhw...@gmail.com wrote: > FIDO has its shortcomings, too, > âand its users can be victims of phishing just as much as anyone else. While a discussion of FIDO is best suited for the FIDO-specific groups, I would just highlight that you're mistaken in this. You can find the FIDO specifications at https://fidoalliance.org/specifications/download The FIDO protocols bind the authentication token to the origin being authenticated with - that is, the UA is a trusted party in the process and provides origin-binding information to the FIDO device. Yes, this means malware is still in scope. No, this does NOT mean "touch here to continue" is valid or a phishable target. It also means that one origin's access to your FIDO device does not affect or influence the ability of other origin's access or capabilities. This is an important difference compared with client certs, particularly when exposed programatically. Further, by defining a limited signing protocol, as opposed to the common "sign this hash" in smart cards, you avoid issues where your email program has the same access as your tax filing program and as your web page. Nominally, you would use different client certificates and keys for each of these, but the actual practice of this is surprisingly less common. Just wanting to avoid perpetuating misinformation. Cheers ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
FIDO has its shortcomings, too, and its users can be victims of phishing just as much as anyone else. All you need is the right inducement. For example...Passwords: Enter your password now or your account will be frozen. Tokens: Enter the token code now or your account will be frozen. FIDO: Swipe your finger on your FIDO device now or your account will be frozen. But back to your original query, Gerv, I would just add the following to all the other good points people have made:From the perspective of HSBC, devices get infected with malware all the time, and sometimes people will want to use that device for their banking. This means that anything associated with a compromised device--passwords, certificates, and even USB security devices--has the potential to be compromised which ultimately can lead to fraud. The way to mitigate some of that risk, then, is to have a completely separate device like Secure Key that you don't plug in to anything.My guess is that that's where they are coming from--the effectiveness of reducing risk weighed against the cost of bank fraud. Relying on client certs wouldn't sufficiently reduce that risk.Still, it's possible that certs could be a better way to go in a different context, and some interesting cases have come up here. It's just a question of picking the right tool for the job.Good discussion!From: Ryan SleeviSent: Friday, September 26, 2014 4:57 AM...However, what I'm surprised to see no one having pointed out is that allof these 2FA systems - including the one you mentioned - is phishing.This is where 2FA systems like FIDO come in to play, because thecryptographic assertion is bound to the channel (like TLS clientcertificates), and thus cannot be phished (as the assertion is no longer abearer token, as it is with those PIN systems). You can see more athttps://fidoalliance.org/___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Le vendredi 26 septembre 2014 11:50:32 UTC+2, Ryan Sleevi a écrit : > On Fri, September 26, 2014 2:39 am, Erwann Abalea wrote: > > Le jeudi 25 septembre 2014 14:29:04 UTC+2, Gervase Markham a écrit : > > > 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? > > > > That needs to be thoroughly checked, but I think it also renders MitM > > impossible on TLS. > > Not impossible. Difficult. Right. Server-only MitM impossible, in the sense of attacking a CA ;) It's clear that if an attacker can get the client's private key or have the client perform crypto operations on its behalf, the client is doomed. In general, if some hostile code gets executed on the client's host, it's finished. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On Thu, September 25, 2014 11:18 pm, Henri Sivonen wrote: > On Fri, Sep 26, 2014 at 12:33 AM, Matt Palmer 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... > > 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"
Re: Client certs
On Fri, September 26, 2014 2:06 am, Gervase Markham wrote: > On 25/09/14 22:33, Matt Palmer wrote: > >> * 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... > > But at any rate, just stick the key/cert in a USB HSM. Problem > > solved. > > Right. That does make it better from this perspective, but a) there is a > risk (depending on design) that key ops can be done without your > knowledge as long as the key is plugged in, and b) surely this just adds > to the system any disadvantages a widget might have? > > But, yes, many other good points. I am being enlightened :-) > > Gerv > Smart cards are not, in and of themselves, guarantees of mitigation, particularly against malware. As you note, it depends on design. That said, for systems where it matter, things like Secure Pin Entry (Part 10 of http://www.pcscworkgroup.com/specifications/overview.php ) exist and are used in real products ( http://www.hidglobal.com/products/readers/omnikey/3821 ), although NSS does not support the CKF_PROTECTED_AUTHENTICATION_PATH attribute with respect to C_InitToken. And, you know, the UX is absolutely horrible for these SPEs (Hey 1990s, we LOVE blocking APIs for things that are theoretically multithreaded but in practice single-threaded), so it's more academic than anything. However, what I'm surprised to see no one having pointed out is that all of these 2FA systems - including the one you mentioned - is phishing. This is where 2FA systems like FIDO come in to play, because the cryptographic assertion is bound to the channel (like TLS client certificates), and thus cannot be phished (as the assertion is no longer a bearer token, as it is with those PIN systems). You can see more at https://fidoalliance.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On Fri, September 26, 2014 2:39 am, Erwann Abalea wrote: > Le jeudi 25 septembre 2014 14:29:04 UTC+2, Gervase Markham a écrit : > > 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? > > That needs to be thoroughly checked, but I think it also renders MitM > impossible on TLS. Not impossible. Difficult. In 'normal', server-authenticated TLS, the client has assurances that the peer (as identified by the certificate) is the same as the peer during the handshake. The server has no such assurances. When performing client auth, the server has assurances that the client (as identified by the client certificate) is the same as the peer doing the handshake. That's because the client cert (and signature exchange) become part of the channel's cryptographic identity. To a degree, Channel ID ( http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 ) does this too, as does any protocol that enforces tls-unique channel bindings ( http://tools.ietf.org/html/rfc5929 ) as part of a secondary authentication exchange (Kerberos, NTLM w/ token bindings, etc) However, this is not in and of itself an intrinsic guarantee against MITM. Any MITM that can obtain the client key can perform the same impersonation. This may be because the user is compelled to yield their certificate/key to the MITM (Yes, this really does exist and happens), or because of malware ( http://www.computerworld.com/article/2493077/malware-vulnerabilities/proof-of-concept-malware-can-share-usb-smart-card-readers-with-attackers-ove.html or http://www.alienvault.com/open-threat-exchange/blog/sykipot-variant-hijacks-dod-and-windows-smart-cards ) that can perform signing operations without user knowledge. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Le jeudi 25 septembre 2014 14:29:04 UTC+2, Gervase Markham a écrit : > 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? That needs to be thoroughly checked, but I think it also renders MitM impossible on TLS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Gervase Markham schrieb: > 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 > > It seems like they have numerous disadvantages (some subjective): > > * Client certs can be invisibly stolen if a machine is compromised > * Client certs are harder to manage and reason about for an average > person > * Client certs generally expire and need replacing, with no warning > * Client certs are either single-machine, or need a probably-complex > copying process > > What are the advantages? With client certs you can build very nice infrastructures which deliver: * Single identity across multiple services without the need to integrate all services into an OTP structure. * Deployable with services from different organisations. * Some kind of "single sign on" for all services on one host (because the browser remembers the latest selected certificate for a given host). * Issuance under strict policies. This helps organisations to enforce security standards and accountability. * Relatively easy to implement on the server side. * Requires https (no possibility to accidentially open a non-https-login-page). * Possibility for central revocation management on the server side. * Possibility to integrate mail encryption and document signatures. Jürgen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 22:33, Matt Palmer wrote: >> * 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... > But at any rate, just stick the key/cert in a USB HSM. Problem > solved. Right. That does make it better from this perspective, but a) there is a risk (depending on design) that key ops can be done without your knowledge as long as the key is plugged in, and b) surely this just adds to the system any disadvantages a widget might have? But, yes, many other good points. I am being enlightened :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 17:53, Robin Alden wrote: > I can send out a million client certificates for negligible > cost. Good point. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On Fri, Sep 26, 2014 at 12:33 AM, Matt Palmer 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... > 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 plat
Re: Client certs
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 > > 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... But at any rate, just stick the key/cert in a USB HSM. Problem solved. > * 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? From a usability standpoint, the Yubikey or USB HSM is better, because it doesn't involve typing. > * 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. > * 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) > What are the advantages? I can't think of any that others haven't already enumerated, so I'll just reaffirm that being able to embed policy OIDs in certificates is *amazingly* useful, and provides the ability to do authentication and authorization without needing an always-on, real-time-capable connection back to the mothership. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Also, policy and authorization is often embedded in client certs. Software that knows how to read this information can provide permissions based on the included policy. This is used by first responders and large distributed networks where the credential acts as their permission to participate and sets the level of participation. IMO, the two really aren't comparable. Sure, there is an overlap for the two-factor authentication portion, but certs are pretty flexible in what you can do. For example, we have some people who restrict use of their software to a particular intermediate (similar to key pinning but before key pinning existed), use client certs to sign documents (without a signing portal), use certs to encrypt email, use certs for scheduling, use certs for directed exchange, etc. Jeremy On 9/25/2014 10:53 AM, Robin Alden wrote: Hi Gerv, I can send out a million client certificates for negligible cost. That is especially attractive cost-wise for an existing system that I have to increase the security of (say over username and password), but which has not been identified as needing 2 factor authentication. Sending out a million anythings by snail-mail is spendy. If you could rely on the user already having the number-sequence widget, or of having a virtual widget on their smartphone (like Google Authenticator) then the cost argument is irrelevant. Regards Robin -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+robin=comodo@lists.mozilla.org] On Behalf Of Gervase Markham Sent: 25 September 2014 13:29 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Client certs 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? It seems like they have numerous disadvantages (some subjective): * Client certs can be invisibly stolen if a machine is compromised * Client certs are harder to manage and reason about for an average person * Client certs generally expire and need replacing, with no warning * Client certs are either single-machine, or need a probably-complex copying process What are the advantages? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Client certs
Hi Gerv, I can send out a million client certificates for negligible cost. That is especially attractive cost-wise for an existing system that I have to increase the security of (say over username and password), but which has not been identified as needing 2 factor authentication. Sending out a million anythings by snail-mail is spendy. If you could rely on the user already having the number-sequence widget, or of having a virtual widget on their smartphone (like Google Authenticator) then the cost argument is irrelevant. Regards Robin > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+robin=comodo@lists.mozilla.org] On Behalf Of Gervase > Markham > Sent: 25 September 2014 13:29 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Client certs > > 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 > > It seems like they have numerous disadvantages (some subjective): > > * Client certs can be invisibly stolen if a machine is compromised > * Client certs are harder to manage and reason about for an average > person > * Client certs generally expire and need replacing, with no warning > * Client certs are either single-machine, or need a probably-complex > copying process > > What are the advantages? > > Gerv > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 2014-09-25 15:12, Gervase Markham wrote: simply means that you can only use it on a computer which has an appropriate and available slot for the token to go into. They can usually be connected using USB, but it's probably not easy to connect that to your phone, and you probably don't always have that with you. (And then, you have the problem that token operations could be taking place without your knowledge.) If your software doesn't ask you to confirm before using your certificate, something seems to be wrong to me. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 13:53, Kurt Roeckx wrote: > On 2014-09-25 14:29, 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? > > You seem to be under the impression that client certificates can't be on > a token. No, I understand that can be true. But then the question is "why bother", as putting a cert on a token, as opposed to having a screen you read a number off, simply means that you can only use it on a computer which has an appropriate and available slot for the token to go into. (And then, you have the problem that token operations could be taking place without your knowledge.) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 13:45, Michał Purzyński wrote: > In order to leak the private cert you need to compromise the host. > Leaking the password is easier - you can compromise the web > application, the target server, the target company or the client’s > machine. You have a few more attack vectors with passwords. > > Passwords get leaked on things like pastebin. The output of a widget like the one I linked to is not a password in the sense you mean with most of your criticisms. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 25/09/14 13:43, Steve Roylance wrote: > You can encrypt communications if you have a public/private key pair You can; although most often that's provided by the server in the model of computing most prevalent on the web today. > You can digitally sign (with the full support of digital signature laws) Yep, OK. > Through federation you can use your ID in multiple places Well, you can carry the widget around too :-) > I agree that it would be great for all members of the eco system to work > together to improve some of the issues you say are disadvantages, but I do > disagree with one of your items. A digital certificate has an end date. A > secure key has a battery with no specific end date so one definitely has no > warning capability. Well, often there's a "battery low" message or light. Whereas I think it's most people's experience that certificate-use UIs don't pop up helpful messages like "Hey, this cert you are using expires in a week. have you thought about getting a new one?" And yes, I take your point about improving the UX... but that was where my thoughts started. Perhaps the reason that the client cert UX is unloved is that they don't meet common use cases? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
On 2014-09-25 14:29, 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? You seem to be under the impression that client certificates can't be on a token. For instance the Belgian government issues national ID cards with a chip on them that has a authentication and signature certificate on it and requires a PIN number. They can then be used to log in on the government website for instance to fill in your taxes. There are other websites like hospitals that support it too. But I would agree that client certificates stored on a computer should probably be avoided for the general public. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
In order to leak the private cert you need to compromise the host. Leaking the password is easier - you can compromise the web application, the target server, the target company or the client’s machine. You have a few more attack vectors with passwords. Passwords get leaked on things like pastebin. Passwords get emailed unencrypted and/or send over insecure channels, like public network + IRC and/or HTTP. Password needs to be remembered, so it will be easy and reused across multiple sites. Yes, there are password managers, but users who care enough to use them, aren’t usually the ones to use easy passwords anyway. Enforcing strong passwords does _not_ work - MyStrongPass201205*, MyStrongPass201206*, MyStrongPass201207* etc passes all security checks and this scheme can be used as long as you want, even when you are forced to change it every 30 days :-) And yes, people do that. Passwords need to be changed when someone leaves the company, frequently a troublesome process which is hard or even cannot be automated. There are always systems that can’t use any form of centralised authentication. Certs are revoked easily. Passwords tend to be shared and never changed after someone leaves. Kind of similar to the previous point. And last but no least - a few years ago, I enforced using client certificates instead of passwords - for systems that contractors accessed. I visited the contractor office and there was a whiteboard with EVERY client’s IP+user+password on it. Everyone, except the company I was working for :-) On 25 Sep 2014, at 14:29, 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 > > It seems like they have numerous disadvantages (some subjective): > > * Client certs can be invisibly stolen if a machine is compromised > * Client certs are harder to manage and reason about for an average > person > * Client certs generally expire and need replacing, with no warning > * Client certs are either single-machine, or need a probably-complex > copying process > > What are the advantages? > > Gerv > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Client certs
Hi Gerv, The top ones that quickly come to mind are things like:- You can encrypt communications if you have a public/private key pair You can digitally sign (with the full support of digital signature laws) Through federation you can use your ID in multiple places I agree that it would be great for all members of the eco system to work together to improve some of the issues you say are disadvantages, but I do disagree with one of your items. A digital certificate has an end date. A secure key has a battery with no specific end date so one definitely has no warning capability. Thanks Steve > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign@lists.mozilla.org] On Behalf Of > Gervase Markham > Sent: 25 September 2014 13:29 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Client certs > > 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-ke y > > It seems like they have numerous disadvantages (some subjective): > > * Client certs can be invisibly stolen if a machine is compromised > * Client certs are harder to manage and reason about for an average > person > * Client certs generally expire and need replacing, with no warning > * Client certs are either single-machine, or need a probably-complex > copying process > > What are the advantages? > > Gerv > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
