Why is client certificate authentication not more common

Question

In my understanding client certificate authentication is not especially complex to implement and have several benefits compared to password authentication

• The secret (private key) does not have to ever leave client machine.
• The server side breach does not endanger client accounts in other services
• The user can remember single master password to his key - or preferably have the key unlocked by OS login - instead of trying to remember per sit login

But I do not remember using any site on the internet that offers this authentication variant (I'm not saying that there are none but my impression is that they are not common). Why it is not more common?

I understand that

• The setup is not trivial from the end user side
• The portability of credentials is non trivial
• Some devices may not support it (if I recall correctly android bellow 4.0 did not support them natively for example)

But still why not offer them for sites requiring high security where user is ready to go extra mile to ensure it (say bank sites) or sites that want to provide impression of high security (say bank sites again)?

Or am I mistaken and client certificates are used more commonly that I imagine?

Answer 1

Your three points are pretty valid.

In short: client certificates are unnecessary complicated to average internet users.

tl;dr

The root problem comes from the fact that mutual authentication (TLS) doesn't work the same way for both parties. Explanation below assumes mutual TLS authentication.

Client connects to server and expects some identity confirmations from server in a form of server certificate issued by a trusted authority. If server certificate passed TLS authentication, then we got the right server.

When server is listening on port and client connects to server, server should authenticate and authorize the client. Server must map remote client to a local user database in order to validate permissions and provide personalized content. Here is the difference: client only authenticates the server, but server authenticates and authorizes client.

---

As you can see, client only consumes resources and do not need to authorize remote server. Server is resource producer and should verify if client is allowed to receive requested data, so authorization must be enabled on server side. In a email/password authentication scheme, server maps email/password to a particular account in local database. Server receives this information when user registers on server. Registration with certificate:

1. is hard. Requires sophisticated tools with cryptic syntax and special knowledge;
2. it requires certificate management.

This is where uneducated users will fail. You can remember a email/password combination, so switching between accounts and devices is not an issue. Switching device in certificate-based client authentication will go to nowhere. How easy would be to average user (who is not an IT expert) to move the certificate from his Windows laptop to iOS phone/tablet, for example? Move certificate between Android phone/table and Mac laptop?

Since client doesn't authorize server (do not maintain a local database of valid servers), server can rotate its keys every day and no one will notice this. Server will work as usually.

I disagree with @SyntaxxxErr0r statement that end users are lazy. They are not ready to perform certificate management on their own. And attempts to teach them will result in a food for potential hackers. Again, average internet user isn't an IT expert and is not required to be it. It is a good deal that end users understand email/password combination and it is impossible to ask from them anything else.

But still why not offer them for sites requiring high security where user is ready to go extra mile to ensure it (say bank sites) or sites that want to provide impression of high security (say bank sites again)?

Same story. Internet banking is supposed for everyone regardless of their technical education. That is, my 80 years grandma should be able to use internet bank services to manage her pension and make basic payments. Though, some banks issue to clients a personalized hardware token, but this is an extra investment from bank side. Literally no site in wild Internet will invest in hardware tokens for every user.

another thing to consider: websites offer password reset via email. How this will look in case with certificates? Try to answer these questions and you will figure why certificate-based client authentication is not widespread in wild Internet and won't be for a long time.

Answer 2

The one context in which I've seen client certificate authentication even offered as an option is for server-to-server API permissions.
Even in this context it really hasn't caught on. API keys (basically just very long username-password pairs, suitable for use by robots) are portable, easy to implement (remember, developers are just as lazy as everyone else), and easy to maintain/rotate.

Some particular problems with using client certificates for identification/authentication/authorization:

• You can transmit the public cert out-of-band, and use your private cert for identification, but then cycling certs is a chore, and you need to copy the cert among any parallel servers in the cluster.
• You can use a normal chain of trust in which a signature on a replaceable cert promises that you are who you say you are, but imagine the headache of getting that to work reliably in your dev and staging environments.

We can imagine that this would all be easier if it were already normal practice, but it would never be as easy as conventional tokens/keys, and the advantages would be small.

Answer 3

Likely due in part to the process being both relatively simple enough that anyone could and can deploy a certificate in a matter of minutes, but also complicated enough that people wouldn't set it up correctly.

However, people have the tendency of not setting it up, because it wasn't already set up. Basically, most end users tend to be lazy.