How Password Hashing Works: Salting, Bcrypt & Why Sites Don't Store Your Password
✦ Key takeaways
- A secure site never saves your password as text — it saves a one-way 'hash' of it that can't be reversed.
- A hash is a one-way function: it turns the password into a fixed-length string from which the original can't be recovered.
- 'Salting' adds a unique random value per user, defeating pre-computed cracking tables (rainbow tables).
- Today's safe algorithms are deliberately slow — like bcrypt and Argon2 — to make brute-force guessing hard.
A simple question reveals a lot: when you forget your password, why does a site send you a 'reset' link instead of just emailing you your old password? Because a respectable site doesn't know your password at all. It doesn't store it and can't read it. All it stores is a mathematical 'fingerprint' of it called a hash. This design is the last line of defense protecting your account even if the site's entire database is stolen.
Hashing is a one-way math function: it takes any text (your password) and outputs a fixed-length string that looks random. The word hello through SHA-256 always produces the same long fingerprint. The magic property is that it's irreversible: from the fingerprint you cannot compute the original word. And any tiny change in the input (a single character) flips the whole fingerprint. So at login, the site hashes what you typed and compares it to the stored fingerprint; if they match, the password is correct — without the site ever seeing the password itself.
Invoice & Quotation Maker
Professional invoices that auto-calc & print/PDF in a minute.
But hashing alone isn't enough. The problem is that millions of people use common passwords like 123456, whose hash is fixed and known. Attackers built giant tables mapping every common password to its hash, called rainbow tables, and instantly compare stolen hashes against them. This is where salting comes in: the site generates a unique random value per user (the salt) and mixes it with the password before hashing. As a result, two users with the same password get completely different hashes, and all pre-computed tables become useless.
One last problem remains: speed. Algorithms like SHA-256 were designed to be fast, and speed is a blessing for performance but a curse for passwords — because an attacker can try billions of guesses per second on a graphics card. The solution is deliberately slow functions built specifically for passwords, like bcrypt, scrypt and Argon2. These add a 'cost factor' making each hash take a fraction of a second — imperceptible to you at login, but making billions of guesses hugely expensive for an attacker.
The table shows the difference between the methods:
| Method | Safe today? | Why |
|---|---|---|
| Plain text | ❌ Catastrophic | Password exposed the moment it leaks |
| MD5 / SHA-1 | ❌ Weak | Too fast and broken |
| SHA-256 without salt | ⚠️ Incomplete | Vulnerable to rainbow tables |
| SHA-256 + salt | 🙂 Better | But fast against brute force |
| bcrypt / scrypt / Argon2 | ✅ Recommended | Deliberately slow + built-in salt |
What's in this for you as a user? First, understand why no respectable site should email you your current password — if one does, it's a red flag that it stores passwords in plain text. Second, because a site's protection also depends on the strength of your password, use a long, unique password for every account (and a password manager to spare you memorizing them), and enable two-factor authentication (2FA). Even the strongest hash won't save password123.