If you have ever looked at a database of password hashes, you might have noticed something: even when two users have the same password, their hashes look completely different. That is not a bug. It is the work of something called a salt, and it is one of the most important concepts in password security.
Let's break down what a salt is, why it exists, and how bcrypt makes it effortless.
What Is a Salt?
A salt is a random string of data that is combined with a password before hashing. Instead of hashing the password alone, you hash the password plus the salt. The result is a hash that is unique to that specific password-and-salt combination.
Here is a simple illustration. Imagine two users, Alice and Bob, both choose the password "password123" (please do not do this in real life).
Without a salt: - Alice's hash: 64f8b5c3... (SHA-256 of "password123") - Bob's hash: 64f8b5c3... (same thing, identical)
With a salt: - Alice's hash: hash("password123" + "x7K9mQ") = a1f3e8c2... - Bob's hash: hash("password123" + "p2R5nL") = b9d7f4a6...
Same password, completely different hashes. An attacker looking at the database cannot tell that Alice and Bob chose the same password. And more importantly, the attacker cannot use a precomputed table of common password hashes, because every hash depends on a unique salt.
Why Salts Exist: Defeating Rainbow Tables
Before salts were widely used, attackers had a devastating tool called rainbow tables. A rainbow table is a massive precomputed list of passwords and their corresponding hashes. An attacker generates this table once (it might take days or weeks), then uses it to crack any database of unsalted hashes almost instantly by looking up each hash.
The math is brutal. A rainbow table for all 8-character alphanumeric passwords using SHA-256 is about 200 terabytes. That is a lot, but it is a one-time cost. Once you have it, you can crack any unsalted SHA-256 database in seconds.
Salts make rainbow tables useless. Because every password is hashed with a unique random salt, an attacker would need a separate rainbow table for every possible salt. With a 16-byte salt (which is what bcrypt uses), there are 2^128 possible salt values. Building a rainbow table for each one is not just impractical, it is physically impossible with any conceivable technology.
Even a smaller salt completely breaks the rainbow table attack. A 16-byte salt means the attacker has to compute hashes from scratch for every single user in the database. They cannot reuse any precomputed work.
How Bcrypt Handles Salts
Here is the best part about bcrypt: it handles salts automatically. You do not need to generate a salt, store it separately, or manage it in any way. The salt is generated and embedded in the hash string itself.
When you call bcrypt to hash a password, here is what happens behind the scenes:
1. Bcrypt generates a 16-byte cryptographically random salt using your system's secure random number generator. 2. It combines the salt with the password and runs the Blowfish-based key scheduling algorithm for 2^cost iterations. 3. It produces a hash string that contains the version, cost factor, salt, and hash all in one string.
The output looks like this:
$2b$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
Breaking it down: - **$2b$** — version - **12** — cost factor - **N9qo8uLOickgx2ZMRZoMyeI** — the 22-character salt (16 bytes encoded in base64) - **IjZAgcfl7p92ldGxad68LJZdL17lhWy** — the 31-character hash
When a user logs in and you need to verify their password, bcrypt reads the salt and cost factor from the stored hash, re-hashes the submitted password with those same parameters, and compares the output to the stored hash. If they match, the password is correct.
You never write code to generate, store, retrieve, or compare salts. The library handles all of it. You just call hash and verify.
Why You Do Not Store the Salt Separately
A common question is: "If the salt is in the hash string, is it not exposed to attackers? Shouldn't I store it separately for extra security?"
The answer is no, and here is why.
Salts are not secret. Their purpose is not to add entropy to the password. Their purpose is to ensure that identical passwords produce different hashes. Even if an attacker knows the salt (and they do, because it is in the hash string), they still cannot use rainbow tables, because they still need to compute the hash for each unique salt from scratch.
Think of it this way: the salt is like a name tag. It identifies which specific hash corresponds to which user. It is not a secret code. The security comes from the slowness of the hashing algorithm, not from keeping the salt hidden.
Storing the salt separately actually makes things worse in some cases. It adds complexity, it creates another column that could be exposed in a breach, and it does not provide any additional security. Just let bcrypt embed it in the hash string.
Salt vs Pepper: What Is the Difference?
People often confuse salts with peppers. They are related concepts but serve different purposes.
A **salt** is unique per password, generated randomly, and stored alongside the hash. Its job is to make sure identical passwords produce different hashes and to prevent rainbow table attacks.
A **pepper** is a single secret value shared across all passwords in the application. It is not stored in the database. It is stored in application configuration, an environment variable, or ideally a hardware security module. Its job is to add protection in the scenario where the database is compromised but the application server is not.
With a pepper, you hash the password plus the pepper plus the salt. An attacker who steals only the database cannot crack the hashes because they do not know the pepper. They would also need to compromise the application server.
Bcrypt does not have built-in pepper support, but you can implement it by appending a pepper to the password before passing it to bcrypt. Just be careful: if you use a pepper, losing it means every password becomes unverifiable. Store it somewhere safe.
The Bottom Line
Salts are one of those security features that work so seamlessly you might forget they exist. Bcrypt generates a unique random salt for every password, embeds it in the hash string, and uses it automatically during verification. You do not need to think about salts at all.
But understanding why salts exist helps you appreciate why bcrypt is so effective. The combination of a unique per-password salt (defeating rainbow tables) and a configurable cost factor (defeating brute force) is what has made bcrypt the standard for password hashing for over 25 years.
For a broader look at how bcrypt works, including the full hash format breakdown, read our bcrypt explained post. And if you want to see salts in action, try our bcrypt generator and hash the same password multiple times to see how the salt changes the output every time.
