Certificate-Based Authentication for everybody

The context

As you may already know, authentication relies on three factors. To prove that you are who you say you are, you need to provide some evidence, either:

  • Knowledge: Something you know. Probably the most familiar and usually takes the form of memorizing or keeping some password to use in the login screen.
  • Possession: Something you have. Usually some form of hardware device (a card with a chip, proximity cards, numerical tokens, etc).
  • Inherence: Something you are. Relies on biometric factors (like fingerprint scanners, retina scanners, etc)

The vast majority of websites rely on the first method, which is relatively safe if it’s done on an encrypted connection, if the hashing mechanism is better than SHA1, and if the password hash is also salted. So far so good. (Note: this is not the state of the industry by far, but let’s ignore that and assume it is.)

The problem

The amount of sites and services we use is cumulative and keeps growing. Every week I end up with some new registrations to sites that I may want to return to eventually. So as a user, I’m experiencing an overwhelming amount of tuples (site/user/pwd) that I have to store.

Furthermore, we are constantly being asked to come up with longer passwords (or passphrases) or generate “really strong” ones (which are not easily readable or rememberable by humans). So the memory option, which was the original idea, has progressively been eliminated, unless you have some big balls (or are just really naive) and you get away with using ‘12345678’ for everything.

There are some solutions to the password issue:

  1. Reuse the same credentials on every site;
  • Keep forgetting the password, and recover the password every time you need to login;
  • Use Google or Facebook OAuth;
  • Use a password manager that keeps them for you;
  • Let the browser manage them

The downsides of each of these approaches are, respectively:

  1. Reuse the same credentials:
    That’s really bad from a security point of view, because once the weakest link in the chain of sites gets hacked, or someone guesses your password, this will collapse on you until you lose all your digital identity, so please stay away from doing this (also if you are still doing this, please tell your grandkids not to do it)
    Some sites have a different complexity pattern for passwords, so you have be creative anyway
    Some sites have different expiration dates and reuse policies, so you have to rotate the password out of sync, and you’ll end up with a diaspora of semi-similar passwords. This doesn’t scale.

  2. Password Recovery:
    So 1. leads sooner or later to 2. This is not an actual strategy but the lack of one so I won’t discuss this. It is also arguably the least efficient.

  3. OAuth:
    Ok, so if you are really concerned about your privacy, why would you let Google and Facebook have all the information about all the sites you are logging into? (ok they have this information anyway, but they shouldn’t!!!) I’m not being paranoid here, it’s just that I don’t want to depend so heavily on a company like Facebook for the security of my login information. And it’s a double-edged sword anyway, because the site you’re logging into will then ask for permission to know things about your Facebook profile, your friends, your activities… and the list keeps growing.
    It creates another memory problem. Sometimes I don’t even recall how I had authenticated on a given site. “Did I use Google, Facebook, or my email here?!” But that could just be me.

  4. A password manager: (i.e. keepassx)
    This is my preferred option to be honest, for sites that matter. The functionality is simple, a database to all your passwords, that you access by a keyword, and perhaps also some one-time-generated random file. The main problem with this approach is that it works as a Single Point of Failure. Losing your key will spell disaster. The more sophisticated versions are of course, paid.

  5. Using the browser:
    What I dislike about this approach is that you actually don’t know your password after you let the browser save it, and you will never again feel free to blindly clean up all your browser data. Furthermore it’s a good practice for a website to ask for the password when performing some critical actions, even if you’re already authenticated, but you can’t enter it if you don’t have it.

Of course you may use a combination of the above based on how you prioritize your accounts, but all this is a full burden on the user’s shoulders. I’d argue there are better options (almost) available -- in terms of both security and usability.

The Solution

Entering the Era of Certificate-Based Authentication.
So now that HTTPS is slowly becoming the standard, mostly thanks to Let's Encrypt, people are being exposed to the idea of certificates more regularly (at least when they encounter a problem like cert expired, self signed, etc). Explaining digital certificates in full is outside the scope of this article but it is a digital file, which contains:

  • The subject’s name and some other personal info previously provided (the entity name);
  • The entity that issued the certificate and all the entities in the hierarchy until the top (or root). These Certificate Authorities (CA) are well known organizations (Verisign, Let's Encrypt) whose business is to issue this certificates and who already come installed on the browser, so you can trust the websites when using the SSL protocol because this chain is verifiable from the root to the current one being evaluated;
  • Validity period;
  • A public key and a hashing algorithm used for the cryptographic session handshake.

I think it is time for the users to start handling certificates instead of logins, but this time these are issued by the website on behalf of you, extending from the same chain of CA that they use for HTTPS.

How would this work?

  1. The user registers on a website with his email and additional optional info, and receives the certificate by email.
  • The user would have to add the certificate on the user trusted certificates database, the keystore. This could be at browser or system level.
  • Next time the user tries to authenticate on that website, the browser would pick up the certificate and ask the user in a modal dialog if he wants to use that certificate to login in.
    (there could be more than one if you wanted to have multiple accounts)
  • Profit!

You could add an extra multi-factor level of security, perhaps adding a 4 digit pin to be entered once the certificate is selected to be used. This pin would have to be set up on the registration process of course, and will lock (revoke) the certificate after a few invalid attempts.
This would be truly multi-factor authentication, in the sense that we are using something we have (the digital certificate) and something we know (the pin). But this is very far from standard AFAIK.


Portable: you can export your keystore and take it with you (if you dare!).
Revocable: in case of a security breach, the certificate could be revoked immediately, which is better than waiting for the next time the user logs in to make him change the password, or to disable an account. There isn’t an analogy in the user/password model that I can think of.
On each expiration, the website could send a new certificate with the encryption level upgraded according to the state of the security at that moment (i.e. SHA-2 family), totally transparent to the user.
No more user/password dumps (or super-scary headlines about them) from server side breaches that compromise the accounts -- the certificates are stored, decentralized, on each client, and only they are accountable for them.


From the flow above, the second step (having the user store the certificate in the keystore) could be the trickiest part, but it’s actually really simple. Here is one simple how-to for Firefox. And being too optimistic, how long would it take the Google team to add some feature in Gmail to identify these certificates and automatically add them to the browser keystore with your consent?


So, if browsers already support this, and, as I (hopefully) made the case, it is that much more convenient, why is it so rarely used? I honestly don’t know, but if I had to come up with a theory, I’d say that the user/password is the main evolution path, and the variability around them is quite small. It would take a full revolution from a big player to change this paradigm. Furthermore, no big player would benefit from it -- on the contrary, I’d say they are quite content as is, providing OAuth for all your logins. So I guess the revolution should come out from NGOs like Mozilla, Let's Encrypt or other White Knights that try to make the internet a better place.