Home / Knowledge hub / Salt
Knowledge hub
Salt
Random data added to each password before hashing so identical passwords differ.
What it means
A salt is a random value stored with each password and mixed in before the password is hashed. Two people who choose the same password then end up with different hashes. NIST describes it as a non-secret value used in a hashing process.
The salt is not a secret and is stored in the open beside the hash. Its job is not to hide anything. Its job is to make an attacker repeat the whole cracking effort for every account, instead of once for all of them.
Why it matters
If your user table leaks, salts decide how bad it is. Without them, one pass through a list of common passwords cracks every account that used one, and identical hashes show instantly who shares a password. With them, the work is repeated per account.
Salts also make precomputed lookup tables, such as a rainbow table, useless. That is a real gain, but it is not a cure for weak passwords. A salted hash of "password123" is still found quickly. Pair a salt with a slow, purpose-built hash.
How it shows up
Modern password hashing libraries create and store the salt for you. bcrypt and Argon2 produce a string containing the salt, the settings and the hash, so there is nothing extra to manage. The risk lies in code that rolls its own scheme.
The mistakes repeat: one salt for the whole application, a salt taken from the username or email, an unsalted fast hash such as plain SHA-256, and a salt that is too short. A site-wide secret added on top is a different thing, called a pepper. Check how the password column is written.
Questions people ask
Salt, answered
Does a salt have to be secret?
No. It is stored alongside the hash and is expected to be readable by anyone who sees the database. Its protection comes from being unique and unpredictable, not from being hidden.
A secret added on the server side is a pepper, which is a separate measure.
How long should a salt be?
OWASP and NIST guidance generally point to at least 16 bytes of random data per password, generated from a secure random source. Longer is not harmful.
Most modern libraries choose a suitable length for you, so rely on their defaults.
Is a salt the same as a pepper?
No. A salt is unique per password and stored with the hash. A pepper is one secret shared across the application and kept away from the database, for example in a key store.
See pepper for how the two work together.
Does salting make weak passwords safe?
No. It stops bulk cracking and precomputed tables, but a guessable password is still guessed when an attacker targets that single account. A slow hash raises the cost of each guess.
Password rules and breached-password checks still matter.
Can we use the username as the salt?
It is better than nothing, but not good. It is predictable, shared across other sites that use the same username, and can repeat when a user changes their password.
Use random bytes generated fresh for each password.
Sources
Where this comes from
Related
Terms that sit next to this one
Hashing
A one-way transformation, so a password can be checked but never read back.
Pepper
A secret added to every password hash and kept outside the database.
bcrypt
A deliberately slow password hashing function with a built-in salt.
Rainbow table
A precomputed list of hashes used to reverse unsalted passwords quickly.
Argon2
A modern password hashing function that is slow and memory-hungry on purpose.
What does your password table reveal?
We check how your app handles sign-in, resets and stored credentials, and where a code review is possible we point to the line that writes the hash. Findings carry the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.