All articles

October 26, 2026 · 1 min read

Password hashing: hashed, never encrypted

A site should never be able to read your password back, not even its own team. Hashing, explained with a meat grinder.

  • security
  • basics

When you create an account, the site keeps your password somewhere. But how can it keep it without being able to read it? Here is the difference between encrypting and hashing.

Encrypting: one key, one risk

Encrypting means locking the password with a key. With the key, you open it again. That is exactly the problem: steal the key and everything can be read. Every password of every user, all at once.

Hashing: a one-way grinder

Hashing means putting the password through a grinder. "sunshine" goes in and comes out as a string of characters unrelated to it, like 9f3a…. That fingerprint is one-way: nobody can rebuild "sunshine" from 9f3a…. Not even the team that stored it.

So how do you check a password?

The database only holds the fingerprint. When you log in, the site does the same thing to what you type: it hashes it the same way, then compares the two fingerprints. Identical? Right password. The site never needed to read it back.

Remember

Hashed, never encrypted. If the database leaks, thieves get fingerprints, not passwords.

For developers

  • Use an algorithm designed for passwords and deliberately slow: Argon2id or bcrypt. Not MD5, not SHA-1, not plain SHA-256.
  • Add a salt (a random value unique to each password): two users who both choose "sunshine" do not get the same fingerprint. Serious libraries do it for you.