Our development server at work is authenticated using client-side certificates that I install on every employee's computer (along with our Root CA cert). This takes me about 5 minutes to generate for them [1] and another 2 minutes to put into their OSX keychain. It's fun to sit there with each person and show them what I'm doing and how this wonderful system works.<p>But if I asked ANY ONE of them to do ANY step along the way, they'd throw their hands up and quit. My brother who is extremely tech competent can't do this. I like these suggestions but I just don't know fundamentally if this system can be used by people without a drastic overhaul to the UI.<p>[1] <a href="https://github.com/TeachBoost/pki" rel="nofollow">https://github.com/TeachBoost/pki</a>
Actually there's not a lot of work for browsers to do. Polish UI, make "logout" button, provide JS API, allow apps to handle errors better. Actually they should provide JS API to work with standard security cards and that will help to extinguish Java Applets from a lot of places. Not a lot of work, but it might start new era of web security.<p>I always wondered, why password-bases authentication is so prevalent, when asymmetric cryptography is there and actually used under the hood. That's a dream: one key to rule them all and no security problems with leaked accounts, unified UI to register, login, logout.
There's a fundamental problem with client certs as currently implemented in browsers as well as the <keygen> tag: these certificates aren't origin-bound and violate the same-origin policy.<p>The method of authorizing client certs without using the same-origin policy is the source of the horrible UX problems: ask the user (often without a "remember this choice" checkbox, so users were asked every session)! Determining which certificate to use can be difficult depending on the subject/issuer, and in general this is a terrible choice to ask a user to make.<p>The problem gets a <i>lot</i> easier if you use origin-bound certificates:<p><a href="http://www.browserauth.net/origin-bound-certificates" rel="nofollow">http://www.browserauth.net/origin-bound-certificates</a><p>With origin-bound certs there's a clear and unambiguous answer as to what cert to use for a given origin by-design. These certs can either be dynamically provisioned in a browser or device-locked to e.g. a Yubikey U2F token. There's no need to ask the user anything more than to push the button on their hardware token if they have one. Otherwise the process is completely automatic.<p>I really don't think efforts to use in-browser client cert authentication that don't respect the same-origin policy are going to get anywhere because of this problem.
If this has to take off, even with browsers providing an easier UI to create and manage client side certificates, two things would be important to avoid confusing users and a lot of "<insert browser name here> is crap and broke my login" messages:<p>1. Easy sync of the certificates across devices (as mentioned in the article, allow the user to choose which ones to sync). Most (non-tech-savvy) people still don't use password managers, and instead remember or write down passwords. You have to make it easy for these people to use multiple devices without having to jump through hoops. Even private keys protected by a passphrase/password add one more barrier (assuming each user has a separate OS account and is logged in). How would a user setup a new device with a previously setup client certificate? What fallback mechanisms (other than form based user/password auth) would be required for cases where a user wants to use a public computer or a shared computer account?<p>2. Handling the reissue of client side certificates for the expiring/expired ones along with revocation (if/when necessary). I believe this is a huge topic by itself on both the usability and security fronts. What would be the sweet spots for the expiry enforced for a particular site? Six months? One year? Two years? Ten years? Considering that most users in the current form based authentication scheme rarely change passwords, the convenience, or rather, the reduction in annoyance to end users, should be an important consideration.<p>I have seen client side certificates used in corporate environments where the management of these is easier, but even in those cases I have always seen alternatives like form based authentication available, along with other things like NTLM, etc.<p>Please comment/inform if any/what prior work has been done in these areas (I'm sure many people must have thought about these).
Back in 2008 I have blogged (<a href="http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/" rel="nofollow">http://pilif.github.io/2008/05/why-is-nobody-using-ssl-clien...</a>) about client certs. The UI around them is horrendous and they also serve as a very good solution to uniquely identify clients across sites. This was a good idea, but in its current implementation it's unusable.
One problem is that keygen is either deprecated or not supported. So you have to create the client cert on the server, then have the user download it (including private key). Or the client has to create a signing request and then upload it to the server, and then download the certificate.<p>Once that is done though, client certificates works pretty well, the browser will pop up a "what certificate to use" dialog when entering the web site. And the server (nginx) will send all the details like name, city etc to the web-server application.<p>Another problem vs passwords, is that the user has to copy or download the certificate to each computer device. And just like passwords, you need to have a process for identifying the user in case he lose the certificate/key.
Mobile browsers/devices handle client certs better than any desktop I've seen. Especially since they have hw trusted storage.<p>The issue is identity/linkage. If they let you set up an arbitrary number of keys, so you could do one per site, that's fine (and really, if you use the same username everywhere it's sort of the same thing)
Good set of recommendations. Client-side certificates are great for securing web applications in a corporate setting, but the client-side is indeed a bit rough in the UI — although once set-up, it is no hassle at all.<p>A major benefit of client-side certificates, is that you can increase the security of all internet-facing web applications you have by routing all external traffic through a gateway proxy, and performing the certificate check there. We use Nginx for that, and host applications such as GitLab, MatterMost, OwnCloud, and DokuWiki that way (performing authentication with LDAP so users can log in with the same credentials on all services).<p>I'm not sure I agree with his suggestion of having the ability to automatically synchronize client-side certificates between devices. I would rather have that be a conscious (security) choice rather than an automatic feature.
Actually creating client side certificates is quite easy if you use the <keygen> tag. See <a href="http://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation" rel="nofollow">http://www.w3.org/2005/Incubator/webid/spec/tls/#certificate...</a>
Sadly some browser vendors have been threatening to remove that functionality rather than trying to improve it. But see the work by the Technical Architecture Group There is also this document now produced by the TAG.
<a href="https://github.com/w3ctag/client-certificates" rel="nofollow">https://github.com/w3ctag/client-certificates</a>
We're using client certs for some mobile sites. But it hasn't been an ideal experience. Has anybody else experienced a problem where Android prompts for selecting which cert to use for a given site every time? iOS seems to remember which one to use for a specific site, but Android prompts EVERY time. I can't tell if it's just something misconfigured, or if its just the behavior of the OS by design.
There's almost no point of client certs for consumers without smart cards. Malware can steal your certs. People lose them or delete them or don't sync them.<p>Can we not devise a system to use our existing bank cards (with chips on them) to store client certs too?
This is interesting , to use cross device there needs to be a vault of some kind to share btw browser would it make sense to have a recommendation for that also , so it would be standardized ?