What is a rainbow table?
A rainbow table is a precomputed lookup tool that lets an attacker reverse a password hash into the original password without recomputing hashes for every guess. It trades disk space for speed, and it only works against hashes that were stored without a salt. Once an attacker holds a stolen hash database, a matching rainbow table can crack common passwords in seconds.
The problem it exploits: unsalted hashes repeat
A hash function always maps the same input to the same output, so without a salt a given password produces an identical hash on every system in the world. That lets an attacker compute hashes for enormous numbers of candidate passwords once and reuse the results against any breach forever. A simple lookup list of password-to-hash pairs would be huge, which is the gap rainbow tables fill.
How the chains save space
Instead of storing every pair, a rainbow table stores chains. It alternates the hash function with a reduction function that maps a hash back to a plausible password, building a long chain and saving only the first and last values. To crack a hash, the attacker runs the chain operations until a stored endpoint matches, then walks that chain from its start to recover the password. The result is a time-memory trade-off: far less storage than a full table, at the cost of some computation per lookup.
Why salting defeats it
A salt is a unique random value added to each password before hashing. It makes every stored hash different even when two users chose the same password, so a precomputed table built for the bare password no longer matches. An attacker would need a separate table for each salt value, which destroys the precomputation advantage and forces guessing one account at a time. Salting is the named defense; a slow hashing algorithm then makes even that per-account guessing expensive. Rainbow tables have faded in practice because fast GPUs and salting changed the economics, but the concept is still tested.
Rainbow table on the CompTIA Security+ exam
Rainbow tables show up in the credential-attack material under SY0-801 objective 2.5 and in the password-storage material on hashing and salting under objective 1.3. The scenario phrase to watch is precomputed hashes or a lookup that reverses unsalted hashes; the correct countermeasure is a unique salt per account. Do not confuse the table with the dictionary attack that builds guesses on the fly, or with a slow password-hashing algorithm such as bcrypt, which slows guessing rather than preventing reuse of precomputed results.