When the impact of the OpenSSL Heartbleed vulnerability became clear (along with many other recent compromises), security experts advised us to change all of our online passwords as a precaution.

Of course this is a Good Idea™, but did you actually do it or was it just another of those pieces of advice about passwords that you thought about and then chose to ignore because it seemed like a massive hassle?  Did you promise yourself that you would get around to it at some point and yet probably you never will, despite an uncomfortable nagging feeling of insecurity at the back of your head?

If so, you are most certainly not alone.  What about the other pieces of advice we are given about passwords?

• “Never reuse your passwords”
  Many people use the same password for almost all sites, or at best a slight variation.
• “Passwords should not contain dictionary words or derivatives”
  How many of you could hand on heart say that none of your passwords contain words found in a dictionary (or commonly used derivatives such as ‘w0rd5′) or somewhere on your social networking profile?
• “Use two-factor authentication”
  This is a great way to improve security – after you have entered your correct password, the system requires you to enter a temporary code – this is either sent to you (e.g. by SMS, email, etc) or is visible on one of your devices (such as a smart phone) and changes every minute or so.  However, it does make the login process slower and more inconvenient (e.g. you need access to your phone.)

My Personal Password Policy (PPP)

I wrote a blog post back in December 2013 about my Personal Password Policy – explaining the way I handle my online passwords so that they are all:

• unique (no reuse across different sites)
• strong (very hard for crackers to guess)
• synced between my devices
• stored on disk protected by a single ‘Master Password’

A better world

Let’s stop for a moment and imagine a better world. One where we can log in to any online system using a single ‘secret’ that we can safely reuse for all systems we use. The systems we log in to never learn the secret but they can still prove that we have it (this probably sounds weird to many of you but please bear with me!)  Obviously we need to keep it very safe because it allows access to all our accounts (in the same way we need to keep safe the list of saved passwords that most people allow their web browsers to save to disk and yet probably never think about securing!)  But if we discover that someone else has learned the secret, we can actually revoke it, created a new one, and the systems we log in to will automatically switch to the new one instead.

Now stop imagining because this system already exists and has actually been around (in some form or another) since November 1996! (see the last published version of the SSL 3.0 protocol.)

At its heart is a process called public key cryptography.  It involves a pair of tokens – the private (or secret) key known only to the owner, and a corresponding public certificate that has one or more identifiers (e.g. your email address) and is signed by a trusted person/organisation once they verify that you are who you say you are.

Certificates

The main advantage of certificate-based authentication is that if someone hacks a web server that you use, your secret remains safe.  As a result, you can use the same secret for every server!

Private key is the possession (“something you have”) authentication factor*.  If you only ever store the private key encrypted with a passphrase, and it is not possible for anyone to get hold of the decrypted private key, the process effectively becomes two-factor authentication as someone needs both the encrypted private key (possession) and the corresponding passphrase to unlock it (knowledge).  You’d only have to remember this single passphrase and would never need to supply it to anyone else or any website.

* = a private key can quite easily be duplicated and could, theoretically, be reproduced from human memory so perhaps it’s not strictly speaking a possession factor but a knowledge factor.  The grey area between possession and knowledge is, however, outside of the scope of this blog post.

Passwords vs Certificates

Portability

How easy is it to log in from new devices?
Passwords: Easy provided you can remember the password (or write it down.) (+1)
Certificates: Quite easy but you need to have your private key and certificate with you. (-1)

Quantity required

How many of these secret tokens do we need?
Passwords: Experts recommend having a unique password for each account – so we might need hundreds. (-1)
Certificates: You could use just one! (or maybe multiple certificates derived from the same private key) (+1)

Simplicity

Is the system easy to understand?
Passwords: People are very comfortable with the idea of passwords and how to use them (+1)
Certificates: Certificate and key pairs are more complicated and people are not familiar with them yet. (-1)

Security

Passwords: You have to share your secret with the server so if someone hacks the server, they may get your password.  There is a lot of conflicting, confusing advice about how to create hard to guess passwords but a password’s strength generally corresponds to how ‘odd’ it is and humans are generally quite predictable and struggle to remember and use ones that are truly ‘odd’ (e.g. randomly generated ones.) (-1)
Certificates: The secret isn’t shared with any server.  The private key itself is randomly generated and thus there is no chance of guessing using ‘popular’ keys.  If you think that someone else has access to the private key, the corresponding certificate can even be revoked so that all (well configured) systems will refuse to accept it any longer. (+1)

Why aren’t we all using certificates already?

If certificate-based authentication is so great, why isn’t it more popular?

• Websites won’t use it until people want it and until web browsers support it with a nice friendly interface for it
• Web browsers won’t make a nice friendly interface until lots of websites use it and/or until lots of users want one
• Users aren’t requesting it, probably because most aren’t aware that it is a possibility (something this blog post hopes to change!)

Let’s see it in action

I made a demo site called Certs ‘R’ Us that allows you to log in with an SSL client certificate, either one generated and signed by the site itself or one from a genuine Certificate Authority.  It’s not the prettiest of sites but it demonstrates the process nicely on recent versions of Firefox and Chrome.  Safari had a few problems in testing and Internet Explorer should work but only with certificates generated elsewhere.

Please leave any feedback as a comment to this blog post.

The source code of the site (written in PHP) is available on the fubralimited/catn-ssl-login-demo GitHub repo.

Summary

I hope that you’ve learned a thing or two.  Hopefully some web developers reading will consider adding SSL client certificate support to their websites.  Maybe some of you will try to persuade the makers of your favourite web browser to improve their GUI for certificate authentication.  Thanks for reading.  Stay secure.

History

This post was originally posted on the CatN blog on 11th July 2014 and has been reproduced here with the kind permission of Fubra Limited.