Considering the Security of SSL Client Certs Versus HTTP Basic Auth

2014-10-10

People often overlook this option, but SSL allows clients to have their own certificates for authentication. It’s similar to SSH key authentication, except because it’s SSL, it’s mind-numbingly complicated to setup. For optimal results, you’ll want to have one client cert for each desktop, laptop, tablet, etc. that you want to connect to the site.

Tablets and smartphones are particularly tricky, because they can be stolen so easily. If you have a client cert loaded, my Galaxy S5 forces you to use at least a pin code for unlocking the phone. Sensible, but also more awkward to use.

Given that I was working on an HTTPS site, I wondered how the security of a long, random password (using basic HTTP auth) would be compared to SSL.

Basic auth is transfered in plaintext. The HTTP protocol does support digest encryption for plaintext connections, but that’s unnecessary for SSL.

On the server side, basic auth passwords can be stored in encrypted form. Apache’s default htpasswd uses either MD5 or crypt(), neither of which is adequate.

What about the security of the authentication handshake? Consider that SSL initiates connections with public key crypto, but for performance reasons, it uses that connection to transmit a newly-created, random block cipher key. The server and client negotiate for the specific block cipher, but it’s probably going to be AES128, or maybe something else of around 128 bits.

Therefore, transmitting a password with 128 bits of entropy will be just as secure as AES128. That is, if the password were stronger than this, then an attacker would have an easier time attacking the block cipher rather than the password.

So what do you need to get to 128 bits of password entropy? It’s a function of how many characters are allowed in the password, and its total length. Since we’re talking about characters that can be typed on a keyboard (whichever kind is standard in your country–US for me), we aren’t using the complete space of an 8-bit byte. So we need to get out some math:

H = L * (log(N) / log(2))

Where H is the bits of entropy, L is the password length, and N is the number of characters that you are allowing in your password.

Here’s 90 characters that can be typed out on a US-standard keyboard:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789~!@#$%^&*-_+=[]:;"|<>,.?/{}()

Run that through the formula, and you find that a 20 character password will get you about 130 bits of entropy–more than AES128. If you’re considering against AES256, then 40 characters will go to 260 bits.

Given that, I wonder if it’s even worth it to use SSL client auth over HTTPS. Apache’s password storage needs modernizing, but that can be handled with server modules.