How to Protect Yourself Against Rainbow Tables

So to protect against rainbow tables, one of the things that we can do is to begin salting our hashes, salting our passwords. When we see stories about popular websites whose users and password lists have been compromised, typically this is because one of two problems

occurs: firstly, that the passwords have been stored in plaintext or, secondly, that the passwords have been hashed but the hashes have been locked up using a rainbow tape. Salting helps to prevent this. And good practise is that we salt. Most modern implementations of authentication systems do this by default. But if we’re developing in-house systems or we’re using third-party web services, we need to check that this is in place. This is best practice. So here what we’re doing is we’re changing the hash process slightly. If the same password always results in the same hash, what we can do is enter a shared variable that the client and the server know that is added to the password before the hash is generated.

So now the password is not hashed in isolation. The password has something added to it, what we call a salt. This collectively forms the new hash. So the hash output, now, is not easy to look up on a rainbow table. That’s because the input is no longer just the password. It is something slightly different. So this is a really helpful way of reducing the utility of those rainbow tables.