So I was thinking through things last night and then I had an epiphany. What if we try mimic client certificate authentication for ordinary day to day client authentication? In this post I will attempt to highlight why I had this idea and how it could possibly help in terms data breaches which seem to be happening on an almost daily basis.

Client Certificate Authentication

Without going into the real depths of the mechanics involved with client certificate authentication, I will attempt to give a high level overview of how client authentication works.

When a client connects to a server over TLS (SSL is now dead and should not being used at all), the server presents its server certificate. The client then validates this certificate. When the server responds with it certificate, it can do 1 of 3 things regarding client certificates:

1. Do not prompt for a client certificate (this is the vast majority of cases), and the TLS handshake proceeds forward.
2. Prompt for a client certificate, but make it option. Meaning if the client does not provide a client certificate, the TLS handshake can still proceed forward.
3. Prompt for a client certifiate, which is mandatory. If the client does not provide a valid client certificate (which the server will validate), the TLS handshake will fail.

Now in order for the client to present its client certificate as part of the TLS handshake, it has to have the private key associated with that certificate. If it does not have the private key, the TLS handshake will not work.

Data Breaches

As we all know data breaches are a fact of life. In terms of what data is breached varies breach to breach, however several breaches have contained user passwords. Now these passwords typically fall into the following categories:

1. They are securely hashed - hashed using a secure hash algorithm, as well as being hashed with a salt.
2. They are insecurely hashed - hashed with a weak algorithm (such as MD5) and/or not being hashed with a salt (making them prone to rainbow table and dictionary type attacks).
3. Worst of all, they are stored as plain text.

This issue is compounded by the fact that many users use the same password in multiple locations.

A Client Certificate Approach

Now getting to the crux of this post. Client certificates have the following advantages:

• The private key is control of the user (i.e. it never leaves their system).
• The client certificate is often public, meaning that anyone can obtain it. However it cannot be used for any authentiction without the associated private key. Meaning if the certificate on its own is leaked, it's not a security risk (it is meant to be public) or a minor risk (potential personal details on the certificate may be leaked).
• So long at the correct algorithms are used to validate the certificate, it is cryptographically secure.
• There is a central issuing authority (a CA) making trust easier to establish.

Now for the disadvantages:

• Not widely adopted.
• Certificates can become quite technical, backing it hard for non-technical users to troubleshoot.
• Certificate revocation is broken.

The idea behnd my approach to leverage the advantages of client certificates, to come up with an alterantive solution to password based authentication. The idea is such that when a data breach occurs, the authentication data is of no use to the attacker. The crux of this solution is that when the authetication data is breached, it does not allow the attacker any access. Just imagine that, service X is breached I no longer need to worry about an attacker gaining access to service y, z, etc, all because I used the same authentication credentials on each. This could also potentially lend itself to become another potential form of Single Sign On (SSO).

I would love to get your thoughts and comments, so please do share them in the comments below.