Save a password

A website must never store passwords in plain text. The day its database is breached — and this does happen — all accounts are compromised, including those on other sites where people have reused the same password.

The first idea: hashing

We store the hash, not the password. When a user logs in, we hash what is entered and compare it.

The website can therefore verify a password without ever knowing it. A database breach only reveals hashes.

Why this isn’t enough

An attacker pre-computes the hashes of common passwords — billions of them — and compares them. These are known as rainbow tables.

Worse still: two people with the same password have the same hash. The leak therefore reveals who is sharing a password with whom.

The salt

A unique random value, the salt, is added to each password and stored alongside the hash:

empreinte = H(salt + password)

Consequences: two identical passwords produce different hashes, and a pre-computed table becomes useless — a new one would have to be generated for each salt.

Computational cost

One problem remains: SHA-256 is fast. A graphics card can test billions of them per second.

For passwords, therefore, we want the opposite of a fast function. Dedicated algorithms — bcrypt, argon2 — are deliberately slow and memory-intensive, with an adjustable cost.

A legitimate user waits 100 milliseconds to log in: imperceptible. An attacker testing billions of possibilities finds their workload multiplied by a million.

Key takeaway: for passwords, we do not use SHA-256 on its own, but bcrypt or argon2. Slowness is a feature here.