How Password Hashing Works
IntermediatePassword hashing is how systems store passwords without keeping the actual password. Instead of the plaintext, you store a one-way hash — a transformation you cannot reverse. At login you hash the entered password and compare. But fast hashes are crackable, so passwords use slow, adaptive algorithms (bcrypt, scrypt, argon2) and a unique random salt per password to defeat precomputed rainbow tables. Done right, even a stolen database does not hand attackers usable passwords.
Think of a one-way blender
Hashing is like blending a fruit into a unique smoothie: the same fruit always makes the same smoothie, but you can never reconstruct the original fruit from the smoothie. To check a password, you blend the one someone typed and see if the smoothie matches the stored one. A salt is adding a unique secret ingredient to each person smoothie, so two people with the same fruit get different smoothies — and an attacker precomputed smoothie catalogue (a rainbow table) becomes useless.
Step by Step
Key Concepts
One-Way Hash
A function that transforms a password into a value you cannot reverse. Verification works by hashing the input and comparing — the original password is never stored or recoverable.
Salt
A unique random value stored alongside each hash and mixed in before hashing, so identical passwords hash differently. It defeats rainbow tables and prevents cracking many accounts with one effort.
Adaptive (Slow) Hashing
Algorithms like bcrypt, scrypt, and argon2 are intentionally slow and have a tunable work factor, making each brute-force guess costly. You increase the cost over time as hardware gets faster.
Pepper
A secret value added to every password before hashing, kept separate from the database (e.g., in a secrets manager). A database-only breach then lacks the pepper needed to crack the hashes.
Key Facts
- Hashing is one-way and used for passwords; encryption is reversible and used when you need the data back — never encrypt (or store plaintext) passwords, hash them.
- Fast hashes like MD5 or SHA-256 are unsuitable for passwords because attackers can compute billions of guesses per second; use a deliberately slow adaptive hash.
- A per-password salt is essential — without it, identical passwords share a hash and precomputed rainbow tables crack them instantly.
Real-World Applications
Storing user credentials
A signup flow hashes the password with bcrypt or argon2 and a unique salt, storing only the resulting hash. Even if the database leaks, attackers face an enormous, per-password brute-force cost rather than a plaintext list.
Upgrading hash strength over time
As hardware improves, an app increases the work factor and re-hashes passwords on next login, so protection keeps pace with attacker capability without forcing a mass password reset.
Frequently Asked Questions
Why should passwords be hashed instead of stored in plaintext?
Because storing plaintext passwords means a single database breach instantly exposes every user actual password. Since people reuse passwords across sites, that also compromises their other accounts. Hashing stores a one-way transformation of the password that cannot be reversed, so even if the database is stolen, attackers do not directly obtain usable passwords — they would have to crack each hash, which strong hashing makes prohibitively expensive.
What is a salt and why is it important?
A salt is a unique random value generated per password, stored alongside the hash and mixed into it before hashing. It ensures that two users with the same password get different hashes. This defeats rainbow tables (precomputed tables of hashes for common passwords) and prevents an attacker from cracking many accounts with the same effort, because each password must be attacked individually. Salting is essential and standard in all modern password-hashing schemes.
Why use bcrypt or argon2 instead of SHA-256?
General-purpose hash functions like SHA-256 are designed to be fast, which is exactly wrong for passwords — attackers can compute billions of guesses per second on modern hardware. Password-specific algorithms like bcrypt, scrypt, and argon2 are deliberately slow and have a tunable work factor (and argon2/scrypt are also memory-hard), making each brute-force guess expensive. You can also increase the cost over time to keep pace with faster hardware.
What is the difference between hashing and encryption for passwords?
Hashing is a one-way transformation you cannot reverse; you verify a password by hashing the input and comparing to the stored hash. Encryption is reversible — with the key you can recover the original data. Passwords should be hashed, not encrypted, because you never need to retrieve the original password, and storing a reversible form means anyone who obtains the key gets every password. Encryption is appropriate for data you must read back later, not for passwords.