A Rainbow Table was a resource used for hacking the cryptographic hash functions in order to discover plaintext passwords by using a pre-computed authentication database. Rainbow table solutions use an algorithm to look up the information needed to crack password hashes quickly. While modern password salting and hashing algorithms have largely invalidated the rainbow table, there are many applications that do not use such readily available tools and instead rely on single hashed passwords due to laziness or inattention to important details.
The idea of using rainbow tables or other hash cracking methods comes from the use of password hashes in authentication databases. Any system that uses passwords for authentication must store those passwords in one form or another. The worst case is that the application developer stores the passwords as plaintext which leaves all registered users’ passwords extremely vulnerable to unauthorized access by hackers or even internal system administrators. While this poor practice has been known for decades it is still common in online applications.
A slightly but arguably pointless thing some programmers do is to perform a single hash computation of the password. There are common hashing algorithms that convert passwords to what may appear to be randomized strings of characters but in reality, are very simple to reverse engineer with a rainbow table. When you authenticate into a system, the password you enter is Hashed using the same algorithm as was used to store the password in the password database. If the hashes match you are successfully authenticated. Here is where a Rainbow Table comes in.
A rainbow table stores all the one-way hashes of plaintext passwords from 1 character in length to 7 or maybe 8 characters in length. (An 8 character rainbow table for a simple hashing algorithm will take up to 32 Petabytes of database space to store!). When a hacker steals a cache of simple password hashes, they can look-up the hash value in the rainbow table to find the plaintext password.
Why is the Rainbow Table mostly Dead?
With the advent of password salting of up to 32 characters, rainbow tables do not exist to perform such look-ups (Source: Rainbow Tables are Dead). More importantly, many standard binaries perform iterative hashing of passwords. This is when a salted password is hashed over and over again, a set # of times, and the final hash value of say, the 764th hash of the originally salted password is stored in the database for future comparison on authentication into the application. Rainbow tables cannot break these passwords.
Why are rainbow tables not All dead?
When hackers steal a cache of passwords they can quickly determine if the passwords were salted and hashed N number of times, by using a rainbow table to look-up the top 100 passwords. If they find a match, they can work backward to determine if the programmers were lazy and did not salt the passwords or hash them iteratively or both. Too often, developers have skipped these important steps so hackers now have your passwords by reverse engineering them on a simple rainbow table.
What does this mean for an SMB?
Rainbow tables are a fast and effective way of cracking unsalted and single-hashed passwords. If you develop an application at your SMB, make sure to ask how the passwords are stored. Ask the developer how large their SALT is (8 is small, 32 characters is sufficient) and then ask how many iterations they do on the passwords before they store the hashed value. LastPass does their password hashing over 100,000 times on the Master Password. That may be excessive for your organization, but a few hundred to 1000’s should be required.
Common salting and hashing functions include: “Argon2, scrypt, bcrypt and PBKDF2“.
Whatever you do, treat this as a critical requirement in your application development. If you cannot build SSO into your password schema, and you need to store password hashes, then you must salt and iteratively hash your password databse using the tools mentioned in this article.