I can log in to a server over SSH without a password, just by using certificates. I could use a password, but it’s not my first choice, and certificates are more usable (for me). Why can’t I do this on websites? It would make things so much easier.
What is a certificate?
A certificate is a series of details that identify an individual. It might include a key (possibly more than one, if it is part of a pair), which is really a very long unguessable number.
Certificates and their keys form the basis of a lot of online security, some of which is visible through the padlock in your browser. If you’ve never done it before, have a go right now:
- Click the padlock at the top of this page
- Click on “more details” or “view certificate”
What you see there is the server’s (the place that sent you the website) certificate, the main use of which is to identify that this blog website is really who it claims to be.
But certificates can be used in a more general sense as a drop-in replacement for passwords, particularly because of how long and random the key material is – it’s like a password on steroids. Perfect for the client (that’s you)!
Why use certificates?
🎲 Randomness – Certificates are inherently random, and very long. This makes them very hard to crack. And because a user can’t choose the content of the certificate’s private key details, you take away the possibility of someone choosing an insecure password, or re-using an existing one.
🔑 Uniqueness – Related to the idea of randomness, it makes it very unlikely that you could end up with a certificate which was already in use, which is unfortunately a big problem with passwords. You can’t do a stuffing attack with certificates.
🧩 Compatibility – Certificates come in a number of standard forms. Often you find that sites put extremely irritating password requirements like a certain set of characters, a certain minimum length, worse still a certain maximum length. With a certificate, the standards are set, taking away the choice to make annoying decisions from websites.
🗃 Safe Storage – Certificates come in a pair. One private, that you keep to yourself. One public, that you can share with anyone. One of the difficulties with passwords is you don’t know that the person at the other end is going to do due diligence and store your password securely. This could lead to it being leaked later on. With certificates, you only ever share the public one, and even if that does get leaked, it’s useless without the corresponding private pair that you keep safe.
📲 0-Click Login – Some websites will refuse to remember your login after a session or a set amount of time, like a couple of days. I have never understood the logic behind doing this. With certificates, the login step happens when you communicate with the web page, removing the need to enter a password, which could be an advantage against shoulder surfing in addition to making logging in more seamless. Of course, user agents ought to allow bypassing automatic login, for example in private browsing modes.
Do we have the technology
…to use certificates for login?
Certificate authentication is built in to HTTPS. Right now the client certificate is mostly used to encrypt the connection and nothing more. It’s only the server certificate that is used for identification (this is what you see if you click the padlock in the browser).
But we could be using client certificates for much more. All it would take would be to re-use your certificate, and then whenever the server sees a certificate for a 2nd time, it matches that up against the database to see who is trying to log in.
Hardware tokens are becoming increasingly popular, and they use a similar idea, although they mostly exist as a form of 2FA, not a primary authentication method.
…to make certificates easy to use?
You can’t remember a certificate. It’s too much work. But like with long secure passwords there are tools that make things easier. Password managers are increasingly used to keep passwords safe. And synchronisation lets you use them across devices. You can store certificates as plain text, so they could be integrated into existing password managers.
Browser are increasingly offering built-in password managers, even offering to generate secure random passwords as a first resort, so there is movement towards making passwords less user-facing. Why not take it all the way?
What about backup
It’s not a good idea to rely on one single method of authentication. You need some kind of backup procedure in case someone loses access.
- 2FA methods have “backup codes” you print out to keep safe, in case you lose your 2FA device or application
- With passwords the email address is often used to mail out a “password reset” link if the password is forgotten
- With email accounts themselves there is often a “recovery” email address used
So figuring out how to make a backup for certificates is a tricky problem.
You could rely on the email address and hope that the user keeps that nice and secure, as websites do right now when they mail you a “reset password” link.
For server side certificates, it is currently considered good practice to make the duration of the certificate quite low, and to renew certificates often. This prevents the spread of damage from mis-issued and stolen certificates.
Similarly, it used to be common advice to change your password frequently in case it was stolen, but this has fallen out of favour in recent times. Partly due to the fact this makes logins very difficult to use. And partly due to the revelation that this resulted in people making easy to guess passwords (like incrementing a number each time) which defeated the whole point of changing passwords in the first place.
With client certificates it makes for a tricky conundrum, and I’m not sure of the best approach to take:
- Change certificates often. Minimising the impact if a user’s certificates should be stolen, but increasing the burden on websites to handle updating these certificates.
- Make client certificates long-lasting. Putting more load on the user to keep their certificate stores secure, but removing the strain on websites to handle frequently updating certificates.
My intuition is that the latter approach is better. A server’s certificates are likely higher value for attackers, and the damage that could come of them being stolen is higher than that of a random end user’s being stolen. And building in a framework to handle client certificates frequently changing seems like a big task that opens up many possibilities for things to go wrong.
This is probably the biggest stumbling block. I said at the start of this blog post that “certificates are more usable (for me)”. The “for me” bit is important.
Pretty much everyone who has used a computer or smartphone will have some vague concept of what a password is and how you use it to log in. The vast majority of the public won’t have any clue what a certificate is, and even if it might be more usable to me, it could just lead to confusion for the wider netizen audience.
To make the kind of change I’m suggesting would take an enormous effort to properly educate internet users, and given how poorly that has gone with regards to passwords, it might be insurmountable.
What do you think about this? Do you have any idea what certificates or keys are before you read this blog post? Do you even know what they are after having read this?
Please leave a comment!
Additional photos by Jan Kahánek