Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Client browser certificates seem to be a nice way to protect sites from intruders - it is impossible to guess and should be harder to steal. Of course, they do not solve all the problems, but they add security.

However, I didn't encounter any public sites using them. Are there sites that use them? Is there some flaw in them that precludes the usage even when security is important or some other reason why there's so little usage of them?

share|improve this question
    
StartSSL.com uses them — instead of creating a name/password, it generates a client cert which is used for login [and must be backed up by the user or else they lose account access!]. At least in the Chrome browser it was a surprisingly pleasant experience. This is the only example I've personally encountered to date. –  natevw Oct 22 '13 at 21:52
add comment

8 Answers 8

up vote 10 down vote accepted

Client side certificated just haven't had a good enough cost/benefit tradeoff. They are very confusing to users so support costs go up. And they are still just bits and thus "something you know" and are vulnerable to a range of software attacks on the browser, the distribution scheme, phishing etc.

Hardware token schemes (two-factor authn) are better for good authn. Single-sign-on (SSO) schemes, potentially federated, and potentially backed by hardware tokens, solve more issues and are easier to deploy.

Managing a lot of certificates would be far more complicated for a user than the current thorny multiple-password issue, and browsers don't offer good support for selecting the right certificate. And if a user uses a single cert for lots of sites, then there are privacy issues since use of the certificate identifies the user.

Over the decades, a lot of us have thought that the age of end-user PK-crypto was just around the corner, especially those like me enamored of the beauty of RSA. It just turns out that the way it has evolved, the help desk and development costs and subtleties and complexities and legal entanglements of real-world PKI keep eating up the benefits.

Equipment seems more expensive than bits, but not if the bits don't do the job, or effective use of them eats up productivity.

share|improve this answer
    
Almost nobody's using 2-factor auth either, but there at least I see the reason - distributing physical tokens has costs. Certs cost nothing though. –  StasM Jan 3 '11 at 21:34
add comment

I use browser certificates for a handful of sites, but as you said mostly not public sites.

The main difficulty in Client Side Certificates is distributing them. That is, how can I securely give you the "all-powerful" certificate that will grant you access to my system, if I don't know you?
Corporate systems are easier, of course, as are systems open to a small circle of partners. But key distribution is always a difficult puzzle to solve. It's much harder than just sharing a password between two parties, considering the private key aspects, and the cert protection, ....

There actually are solutions to this, of course, and I even use one for a "public" website. (It happens to be in the identity business, so it's worth the overhead to them...). That solution is based on primary authentication via password, and after I'm fully authenticated I have the option to download my certificate - assuming I know what to do with it.
Not much better, since the password channel is still open... but that at least gives me the possiblity of changing the password to something impossible and unusable, and have only the CSC....

But this is not trivial, and kinda complex to implement correctly. Distribution would still bug most users.

share|improve this answer
1  
It doesn't have to be all-powerful - you can still ask for a password, for example. You can grant access to low-security areas with password alone and to high-security ones only with cert+password. That's just one model, of course. –  StasM Jan 3 '11 at 7:57
    
@StasM - Well, yes, but again that just raises the complexity of implementation. And if you're doing that, why bother? –  AviD Jan 3 '11 at 8:53
add comment

As I understand it, there are numerous problems with using client certificates in practice. Here are some of the issues I've heard:

  1. Getting client certs. It is a pain for users to initially get a client cert in the first place. Obviously, sites don't want to create unnecessary hurdles that users have to jump through before they can even begin to use their site. (Even having the site generate the client cert and provide it to the client is not a familiar operation for a user -- not to mention that it has security problems, since ideally, only the client should know the client's private key.) Modern browsers provide ways to create or import private keys and client certs, but the user experience is horrible.

  2. I've heard that some servers apparently don't support client certs well (e.g., http://osdir.com/ml/encryption.cryptlib/2005-09/msg00000.html).

  3. Mobility is a problem. Despite all their problems, passwords are very portable; client certs are not. Even if the client manages to generate a private key and get a client cert for it, if they want to start using a second computer, they'll have to do a complicated and confusing dance to transfer the private key and cert over to the second computer. If their first computer dies (or suffers a hard disk failure) and they have to re-install their OS or buy a new computer, and if the client hasn't backed up their private key, they will have no way to put their private key and cert onto their new computer; they're pretty screwed. A site can create a backup method of authentication so users who lost their private key can generate and submit a new private key, but this backup method of authentication can easily become the weakest link in the chain. It doesn't matter how strong your primary method of authentication is, if your backup method is easily defeated.

  4. It's not clear whether there is sufficient support from browsers for client certs. I don't know if all the various browsers out there (including mobile browsers) adequately support client certs.

  5. The PKI model is pretty well broken anyway. The assumption was that the CA would verify the identity of the user (e.g., their real name) before giving them a client cert, and the protocol was designed around this assumption. However today's CAs don't really verify identity. This creates a mismatch between the design assumptions and the reality.

  6. Client certs create privacy risks for users. In some browsers, they enable tracking of users across domains. (All browsers ensure that cookies carefully defend against this threat: only the domain that set the cookie can read it. However, browsers don't incorporate similar protections for SSL client certs.) I don't know if modern browsers have effectively addressed this problem, but it's an area where client certs are relatively immature, as far as I know.

  7. There are annoying technical problems, if the client generates and signs its own client cert. According to the TLS protocol, the server is supposed to first ask for a list of CAs that it's willing to accept; the client subsequently responds with a client cert issued by that CA, if it has one. (Note that this happens before the client has sent a HTTP request, any HTTP cookies, a username, or any other identifying information.) This means that, if you want to use client-issued (self-signed) client certs, then the server has to know the name of the CA that the client is using before the client even authenticates or identifies itself. That's tricky.

  8. Finally, the cherry on the pie: client certs don't solve the phishing problem. They prevent theft of the client's private key, but not other personal information. Bad guys can still set up a fake bank site (which discards any client certs sent to it). The phishing site won't learn the user's private key, but if the user thinks they've connected to the real bank site, they may type in their bank account number, SSN, PIN, etc., revealing that information to the attacker.

All of these translate to poor usability and increased support costs (e.g., helpdesk calls). In short, you can use client certs, at least in principle; it's just that, in practice, doing so is inconvenient for everyone and usability sucks.

More fundamentally, there is a chicken-and-egg problem: until many sites start to use client certs, browser manufacturers will not place a high priority on making client certs usable; and until browsers make client certs usable, sites won't adopt them. To put it another way, if we want to use client certs to solve the general authentication problem, we have to both convince all browser manufacturers to make major changes to browsers, and convince sites to adopt new technology. No benefits accrue to anyone until all these parties make coordinated changes. That's a huge hurdle to adoption.

There are better solutions for secure authentication on the web, involving HTTPS, secure persistent cookies, and email-based recovery. However that's getting beyond the scope of your question.

Last comment: The fundamental challenge in secure web authentication is usability, usability, usability. Making systems that work well for users -- and are secure, when used as ordinary users are likely to use them -- is very challenging, and is all that matters. Crypto is only a tiny piece of this problem.

share|improve this answer
    
The <keygen> element documented in the HTML5 spec (and supported by many browsers before) is a fairly usable way to generate+install secure keypairs on the client. Experience in Chrome was pretty seamless, at least, and I would hope FF as well. –  natevw Oct 22 '13 at 21:57
add comment

I think that mainly they aren't used because the average person (i.e., not you since you're asking this question) can't fathom their usage. There are a few commercial sites that use them but they're usually very special purpose or for automation. For example, Oracle uses client certificates to validate end users with valid support contracts for package updates. But even with highly technical users getting the proper key exchange can be challenging.

All of that being said, I use client certs to protect portions of my websites that I leave open to the public, and I think they are fantastic.

share|improve this answer
1  
I see your point, but that can be all done in the browser... The user should just download/double-click the file and that's it. Browser extensions are very complex things but were made seamless to the user, for example. –  StasM Jan 3 '11 at 7:41
2  
All of that "in the browser" stuff takes quite a lot of code on the server side to implement. –  bahamat Jan 3 '11 at 8:23
add comment

The Estonian National Identity Card is a smart card which contains a client certificate embedded on it. You can get smart card readers for it and use it at home to apply for government services or authenticate to the main Estonian banks. All the user sees is a card/pin prompt and next thing they know they're authenticated.

share|improve this answer
add comment

On of our client uses client certs to authenticate touch-screen kiosks systems. The systems are distributed to dealers, and each gets their CA root cert installed as well as a unique client cert.

The client cert is used to authenticate the kiosk system to the webserver, without requiring the dealer to perform manual authentication on startup of the device. If an individual system needs to be shut out it's easy for our client to revoke the cert.

share|improve this answer
    
See, here distribution is taken care of, it's trivial compared to delivering the kiosks... Though I would question the security of this system, after all anonymous users can access the kiosk directly - and possibly "borrow" the cert? –  AviD Jan 4 '11 at 11:38
    
That's true, AviD. Of course the kiosk should be properly hardened to prevent that kind of access. If a cert is stolen, it can be revoked individually by the CA since that kiosk should be considered compromised. In this case the information on the webserver is not critical enough to require additional measures, so the client-cert is basically an alternative to a password. –  Martijn Heemels Feb 18 at 9:21
add comment

The French Minister of the Economy published a public website for tax management (on-line tax payment, information on deadlines, forms downloading...) which uses SSL certificate for user authentication. The user registration (this role is attributed to a Registration Authority in PKI) which has been pointed by AviD♦ to be the main difficulty in a such project, has been solved since this administration has already enough information to identify the taxpayers.

share|improve this answer
    
The problem isnt just the initial identification, its distribution of certificates. –  AviD Jan 3 '11 at 18:40
    
Yes I was unclear. I meant that the administration is able to to ensure that the identity of certificate requestor (i.e. the private holder) matches and the declared identity. Technically speaking there is a unique private number on the tax payment receipt (of the previous year) used as shared secret during the certificate generation process. –  Jcs Jan 3 '11 at 20:52
1  
Really? they consider this "unique tax payment number" to be a protected secret? Humph... Well, I guess its not worse than U.S. considering SSN to be a form of secure identification... –  AviD Jan 4 '11 at 11:36
add comment

A variation of browser certificates are used in the HTTP/S based ActiveSync protocol.

Several email administrators use certificates to authenticate a mobile devices so that mobile email doesn't suddenly stop working when the user changes their password.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.