Same password, different hash output
Because bcrypt includes a salt, the same password can produce different hash strings each time.
Security & Auth 7 min read 2026-03-12
Bcrypt Password Hashing for Real-World Apps
Why bcrypt exists, when to use it, and what developers should understand about salts, work factor, and verification.
Intro
Passwords need a different kind of protection than general text. If you store them with a fast hash, attackers can test guesses extremely quickly after a breach.
Bcrypt is designed to be slow and expensive enough to make password cracking significantly harder than with generic hash functions.
What is it?
Bcrypt is a password hashing algorithm that includes a salt and a configurable work factor.
It is built specifically for password storage and verification, not for general file checksums or API integrity.
Why it matters
- Dedicated password hashing reduces the impact of database leaks.
- Built-in salting prevents identical passwords from producing identical stored values.
- The cost factor can be increased over time as hardware gets faster.
Examples
Verification compares against the stored hash
Applications do not decrypt passwords. They hash the candidate password and compare securely.
Common mistakes
- Using bcrypt for data that does not need password hashing semantics.
- Choosing a cost factor so low that the protection becomes weak.
- Trying to “decrypt” a bcrypt hash.
- Skipping password policy and assuming hashing alone solves everything.
FAQ
Why does bcrypt output change for the same password?
Because each hash includes a salt. That is expected and desirable.
Can bcrypt hashes be reversed?
No. Verification works by hashing the candidate password and comparing, not by recovering the original password.