Why a password hash can be looked up
A password database should not contain passwords in readable form. Instead, it stores a hash: the output of a one-way calculation applied to a password. When someone logs in, the system hashes the submitted password and compares the result with the stored value. The same password produces the same hash under the same conditions, which creates an opportunity for attackers who obtain the database.
How rainbow tables save work
A rainbow table prepares many possible password calculations in advance. But storing every password and its hash would take enormous space. Instead, the table stores the endpoints of long chains. Each chain alternates between hashing a candidate and using a reduction step to turn the hash into another candidate password. The reduction is not decryption; it simply maps a hash back into the range of guesses the table is exploring.
Given a stolen hash, an attacker can repeatedly apply those steps to see whether it leads to a stored endpoint. If it does, the attacker can regenerate that chain from its start and check whether it contains the matching password. The table trades storage for computation: it can recover some passwords faster than trying every guess from scratch, but it does not cover every possible password, and chains can overlap or fail to yield a match.
Why a salt changes the calculation
A salt is a random value added to a password before it is hashed and stored alongside the result. With a different salt for each account, the same password produces different stored hashes. A table prepared for one salt cannot be reused directly against accounts with other salts, so attackers must do far more work for each account.
That is why rainbow tables are most useful against unsalted password hashes, while modern password storage typically uses unique salts and deliberately slow password-hashing methods. The practical lesson is that a precomputed table is powerful only when the system makes the same guess produce a reusable result.
