Password hashing is how a well-built website stores passwords without actually storing them. When someone signs up, the site runs their password through a one-way function and keeps only the result, called a hash. At login it hashes what was typed and compares the two. The site never needs the original, and nobody can work it back out from the hash.
How a login check works with hashes
A hash function always gives the same output for the same input, but there is no key to reverse it. That is the difference from encryption, which is designed to be undone. Two ingredients make password hashing safe in practice:
- A salt: a random value generated per user and mixed in before hashing. Two people with the password "summer2026" end up with different hashes, so attackers cannot use precomputed lookup tables or crack everyone at once.
- Deliberate slowness: password-specific algorithms such as bcrypt, scrypt and Argon2 are tuned to take a noticeable fraction of a second. That is nothing for one login but makes guessing billions of candidates very expensive. Argon2id won the Password Hashing Competition in 2015 and is the current OWASP recommendation.
What a stored bcrypt hash looks like
A bcrypt hash in a database looks like $2b$12$ followed by about 53 more characters. The 2b names the bcrypt version, 12 is the cost factor (each step up doubles the work), and the rest contains the salt and the hash. Everything needed to check a password is in that one string.
Does this concern a small-business site?
Only if your site has its own user accounts: a members area, a client portal, a shop with customer logins. A brochure site with a contact form stores no passwords. If you do have accounts, use the hashing your framework or auth provider (Supabase Auth, Auth0, Firebase and similar) already does instead of writing your own, or skip stored passwords entirely with single sign-on.
Password storage mistakes
- Using a fast general hash like MD5 or plain SHA-256. They were built for speed, which helps attackers.
- Skipping the salt, or using one salt for every user.
- Emailing users their password. If you can, the site is storing it readable.
- Never raising the cost factor as hardware gets faster. Rehash on the next login when you increase it.
- Relying on hashing alone. Hashing protects a leaked database, not a reused password; two-factor authentication covers that gap.
Related terms
- Encryption: reversible protection, the wrong tool for passwords.
- Two-factor authentication: protects accounts when a password leaks anyway.
- Single sign-on: lets another provider hold the password.
- Backend: where hashing code runs.