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.
🍪 No more cookies – Not from the server you’re trying to log in to, but from any third parties that might want to track you through cookies. Because the authentication happens at the HTTPS level, you can turn cookies off at the browser level and still be able to log in. Any trackers that might want to use cookies would no longer work. 3rd party requests over HTTPS would get the same kind of random client certificate that are used right now.
📲 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?
👍 Yes.
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?
🤷♀️ Maybe.
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?
Unfortunately it’s not well suited for storing certificates.
Challenges
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.
Certificate Duration
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.
Mental Models
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
I know exactly why you wrote this post.
Yup frustrating isn’t it, when we have the mechanism already in place and completely standard to all OSs.
I remember reading someones self-hosted blog a few years ago where they described how they used a cert to log into the site.
When I later got some S/MIME certs from the ill-fated StartSSL I had that same ability to simply waltz into the site like I owned the place.
As long as the cert is installed in your system or browser the site knows who you are with far more confidence and authority than a session cookie..
The only way I see it could work with public sites is if you got the cert when you sign up, just the same way you get one from a cert seller.
Trustability and lack of being a cert authority would not be an issue, as it would be you presenting it back to the site that issued it.
For example we could all easily be logging into our Vivaldi accounts with a cert issued by Vivaldi, and if locked out just resort to the original Username and password combo you signed up with, and when logged in cancel the lost cert and mint another.
Having little idea about certificates, except for pgp which I’m still vague about, I found this easy to read and understand explanation at: https://www.jscape.com/blog/client-certificate-authentication with some extra links.
But do you need a different cert for each site?
If not, it seems to me that the only thing that has to be added at the server end is the (optional(?)) Client cert Request.
How difficult is this to implement for web admins?
Even if not a difficult thing, would we get everyone on board or would we have to put up logins/passwords at some (or most) sites?
To me it seems like a great idea… that will never get implemented.
Pardon the pessimism.
P.S.
Could the certs be stored in something like Cleopatra with PGP certs or the Windows Cert store, the mac Keychain or Linux wallets?
Also I tried for over 10 years to get our management to implement Digital Signatures for our documents, no end of excuses not to. May be a tough battle as most of the top managers have no clue how it works and only think of the expense.