Security Sense: Browsers Are Increasingly Holding Websites Accountable for Poor Security

Website security is one of those continually evolving things. That which we thought to be secure yesterday, we often find to be insecure today. The way passwords are stored is a perfect example: in times gone by, a hash with a function like MD5 was pretty normal. We soon realised that was unsatisfactory, so we moved on and started adding salts and stronger hashing functions such as SHA1. Now that's been proven pretty close to useless, and the goal posts have moved again.

(Just in case this is news to you, check out OWASP’s Password Storage Cheat Sheet.)

The thing about password storage mechanisms is that they're largely abstracted away from the user, and the details are not remotely observable. How a website protects credentials is not immediately apparent, but how it implements SSL is and that's where things are getting kind of interesting.

One of the few independent indicators we have of website security is what the browser reports in terms of the SSL implementation. We've long ingrained into the end user to “look for the padlock next to the address bar” as this was the browser’s way of indicating that traffic would be secure between the client and the server (or at least up until the point that SSL terminates somewhere near the server). This was a very basic implementation – SSL or no SSL – but now browsers like Chrome are taking it to a whole new level.

A perfect example is when you inspect the certificate of a site like my very own Have I been pwned?

In this case, “obsolete cryptography” is due to my dependency on Microsoft’s Azure website service which at the time of writing, still supports the RC4 cipher (it will finally be killed off in July).

Now in my view, Chrome reporting not just on the presence of SSL but the strength of it is a very good thing indeed. When you think of the number of security issues we've had in this space in very recent times (POODLE, FREAK, Logjam, etc) clearly SSL alone is no longer enough, it needs to be good SSL and the browser needs to let you know when it's not.

The goalposts are now moving even further though and it was highlighted very well in a discussion with Absa bank in South Africa just this week:

Here we have a case where a bank is using weak SSL (you may recall my view of “bank grade” security) and the browser is quite rightly warning the end user of this. This is quite literally the browser holding the website accountable and telling their customers to use caution when communicating over the connection which, in my view, is very good advice so kudos to Chrome. What's not such good advice is the bank then telling their customers to ignore the browser warnings! Of course banks have many other security mechanisms in place to protect consumers, but the only thing that protects the confidentially and integrity of their data in transit is the SSL implementation.

Of course we’ve known about this since September with Google announcing certs using SHA1 and expiring beyond 2016 would result in a warning. We’ve also now got the Chrome stable beta channel striking out the padlock and HTTPS scheme in the address bar when the RC4 cipher is detected. As with SHA1 support, this will mean you no longer even have to drill down into the certificate to be told about deficiencies in the crypto, it'll be front and centre in front of everyone. None of this should come as a surprise to website operators, we've known for a long time now that there are certain SSL implementations that simply shouldn't be used any more.

The fix, of course, is easy: strengthen your SSL and the warnings go away which is altogether much better than telling your customers to ignore them! Oh, and they'll also be more secure which is a nice by-product of removing those pesky warning messages which were making customers suspicious.