WordPress 2.5 is out today and it looks mighty impressive. I’m going to wait a few days for reports of compatibility with the plugins I’m using before I upgrade, but after that, expect to see WordPress 2.5 on this blog soon.
Looking through the changes list, I did notice one odd thing. WordPress 2.5 finally adds salt to stored password hashes. It’s nearly inconceivable to me that WordPress went so long without salted passwords — it’s an incredibly important security technique that essentially has zero implementation cost. When I was helping to design the software infrastructure that powers Veropedia, I made sure that password hash salting was in our alpha. And yet it takes the fine folks over at WordPress until version 2.5 to implement it? Did they not realize how important it is to security?
Here’s why password salting is so important. The naive algorithm for storing login passwords in a database is to store them as plaintext. User tries to login, the inputted password is matched against the password field under their username in the database, and if it matches, the login is successful. The reason this is terrible security practice is because if the database is compromised (which is surprisingly easy to accomplish even remotely using SQL injection) the entire list of passwords can be revealed, compromising the entire site and everyone who is registered to use it.
So the next step in the evolution of login security (and this happened decades ago) was to use a one-way function called a hash function to store the password in the database. I won’t go into the details of how a hash function works, but the key point to know is that it is one way: given an input, you can quickly calculate the output, but given the output, you cannot calculate what the input was. So, now password hashes are stored in the database instead of the raw password, and when a user goes to log in, their input is hashed and compared against the value in the database. This is what WordPress used up until version 2.5.
There’s just one major flaw with this seemingly secure system. There are only a few widely-used hash algorithms, and they all necessarily run quickly on small inputs, so it’s trivial to pre-compute a huge list of potential passwords and their associated hash values. This is called a rainbow table, and larger rainbow tables have trillions of entries in them, pretty much guaranteeing a successful attack against less secure passwords (short ones, ones that don’t use numbers and punctuation, etc.). So we’re pretty much back to square one: database is compromised, the hashed passwords are compared with the rainbow table nearly instantaneously, and lots of accounts can be compromised.
That’s where salting comes in. Instead of just storing the hashed passwords, store the hash of the concatenation of the password and some unique value for each user account. This security measure makes pre-computed rainbow tables useless, effectively requiring a huge rainbow table to be constructed for each individual password to be cracked. The extra string that is added to the password before hashing is called the salt. The most commonly used salts are the user account number and the user account name. So whereas before HASH(password) was being stored in the database, now HASH(username . password) is stored (the period is the concatenation operator). It’s literally that simple to implement: add a few characters to one line of code in the web application for greatly enhanced security.
Thus, anyone writing any sort of software that processes logins should use password salting. It’s essentially instant to implement, and it provides huge security benefits. That’s why I’m astounded that it took WordPress five years and two major versions to finally implement it. Who knows how many thousands of sites have been compromised in the interim thanks to its absence? But still, better late than never.