I’ve been developing web applications since 1998, but it was only a couple of weeks ago that one of the fundamental aspects of SSL (Secure Sockets Layer) really clicked into place for me: during an SSL session, the traffic is encrypted with a symmetric algorithm. SSL only uses an asymmetric (public key) algorithm during the session handshake in order to securely exchange the symmetric key for the rest of the session. The bulk of the SSL session is therefore optimised for speed, while the key exchange (the most vulnerable part) is optimized for security. Clever.
I can already see Spence shaking his head in disbelief that I hadn’t known this. My only excuse is that I’ve spent most of my time on inward-facing web apps, rather than public, internet-facing ones. (Not much of an excuse, though, I know.)
While I’m in a confessional mood, I might as well admit that the technique of salting hashes for increased security in storing passwords had passed me by until recently, too.
The real cleverness of salting hashes is not the technique itself, but the recognition of why it’s important. You could just take the attitude that if an attacker has got access to your database, then they can do whatever they like with it anyway, so why bother further encrypting the passwords you store in it? The problem with this is that most people re-use the same password in multiple places. So if an attacker gets hold of someone’s password for their blog, say, then chances are they can use it to also gain access to that person’s email or online banking account.
I’ll take this opportunity to recommend again the Password Safe tool, which removes the burden of having to memorize dozens of different passwords. Go get it, and start using it. If you’re not a computer expert, it’s difficult to spot where the weakest link is in any security chain. Password Safe, at least, will help to make sure it’s not you.
