But server operators can also do a lot to protect users. To start with, you should obviously try to not let attackers access the databases with the hash values in the first place. But that’s easier said than done, as is proven by the large number of attacks on the servers of big companies. You’ll inevitably need to secure the hash value. That begins by not using outdated algorithms.
Both MD5 and SHA-1 have long been considered unsafe, and corresponding rainbow tables are very easy to find online. Passwords that have been hashed this way can be uncovered within seconds. This is why it’s essential to keep yourself informed as to whether there are new algorithms or how safe the used hash function still is. SHA-2 and its best-known variant SHA-256 are still considered safe, but SHA-3 is now also available, which promises even longer safety.
To make decryption using rainbow tables a bit more difficult, you can use something called salt: when a user sets a password, the system also creates a random value, the salt. This value flows together with the password into the hash function and so generates a different value than the password alone.
Salt and hash value are stored together in the database. This can be confusing: attackers who receive the contents of the database have the username, hash value, and corresponding salt. Brute force and dictionary attacks can’t be avoided, but the additional measure particularly helps against rainbow tables. Such a table is created in advance, based on a hash algorithm and independent of the database being used. The salts also can’t be contained in rainbow tables, since the creator of the table didn’t know the salt yet.
Another benefit of salt is that the user can’t make note of it. This means they can be completely chaotic and incredibly long. It makes the hash values themselves so complex that working with them is more difficult. A salt also prevents two or more people from entering the same password and so writing the same hash value into the database. Finally, salt helps with the problem that users insist on using the same password for various services. The stored hash value is different for each service, based on the salt.
In addition to salt, there’s also pepper: this complicates attacks with brute force or dictionaries. Pepper is also a random character sequence incorporated with the password in the hash value – best if combined with salt. As opposed to salt, pepper isn’t saved together with other login data in a database, but instead is separated and stored in as secure a location as possible.
Oftentimes, a set character string is used for all passwords on the platform. So, pepper doesn’t help with the fact that several users have the same password, because they also use the same pepper – which leads to identical hash values. Administrators should select a combination of salt and pepper as a result.