Skip to content
>_ITDITDWeb Security Platform

Glossary

#passwords#hashing#authentication

What is password hashing? Storing passwords safely with a one-way transform

Password hashing stores passwords with a one-way transform you can't reverse. The difference from encryption (reversible), why plain MD5/SHA-256 is unsafe (rainbow tables, brute force), and the right answer — a per-user salt plus a slow hash (bcrypt/Argon2/scrypt) — explained defensively, no attack steps.

Published 2026-06-27 Updated 2026-06-27 3 min read

"Never store a password as-is in the database" — so how do you store it? The answer is hashing. Here's how it works and the key points for doing it safely (no attack steps).

Hashing ≠ encryption

These get confused, but the goals are opposite. Encryption is "reversible with a key, so you can read it back later." Hashing is "one-way — you can't reverse it." A password is information even the operator shouldn't need to read back, so a deliberately irreversible hash is the right fit.

Encryption (reversible)

plaintext ⇄ ciphertext. key reverses it. for data you read back

Hashing (one-way)

password → hash. can't be reversed. for storing passwords

Store passwords with a one-way hash. Encryption (reversible) has the opposite goal.

At login, you check "hash the entered password the same way and see if it matches the stored hash." You never need to recover the original.

Why "raw MD5/SHA-256" isn't enough

MD5 and SHA-256 are fast hashes. That's a useful property elsewhere, but a weakness for password storage: an attacker can compute a huge number of guesses per second against a leaked hash.

  • Rainbow tables: a giant precomputed table of "common password → its hash." With a raw hash, a match is found just by looking it up.
  • Brute force: the faster the hash, the more guesses per unit time — i.e. the easier to crack.

The two fixes

1

Add a salt (a different value per user)

Before hashing, mix in a random value that differs per user (a salt). Now the same password stores differently for everyone, which defeats rainbow tables and stops one cracking run from covering reused passwords across accounts.

2

Use a deliberately slow, purpose-built hash

bcrypt / Argon2 / scrypt let you make the computation intentionally expensive (a cost parameter). A slowness no one notices for a single legitimate login drops the attacker's brute force to an impractical rate. Salting is built into these too.

This site's view: don't build it yourself

"Surely MD5 plus a salt is enough?" — that's the classic trap. Safe password storage also depends on generating and storing the salt, tuning the cost, and handling timing differences. Rather than assembling that yourself, lean on your language/framework's official password function (most use bcrypt/Argon2 under the hood). For new systems, make Argon2id your first choice.

FAQ

QHow is hashing different from encryption?
A

Encryption is reversible: with the key you can decrypt the data back, which is what you want for data you'll read again. Hashing is one-way — you can't reverse it. A password doesn't actually need to be readable back, even by you, so a deliberately irreversible hash fits. Even if the database is stolen, you can't pull the original passwords straight out of the hashes.

QIs hashing with MD5 or SHA-256 safe enough?
A

No, not on its own. MD5/SHA-256 are 'fast' hashes, so an attacker can test an enormous number of guesses per second, and common passwords fall to brute force or rainbow tables (precomputed lookup tables). To make it safe, add a per-user 'salt' and use a deliberately slow, purpose-built hash (bcrypt, Argon2, or scrypt).

QWhich one should I actually use?
A

For new systems Argon2 (Argon2id especially) is the first choice, with bcrypt or scrypt as solid alternatives. All of them build salting and a tunable cost factor into the design. Rather than wiring up MD5+salt yourself, use these standard implementations (your language/framework's official functions) — it's safer and more reliable.