Bcrypt Hash Generator — OWASP-Recommended Password Storage
Adjustable cost factor · Password strength meter · Benchmark · Verify mode · Code snippets · 100% browser-side
Enter a password and click Generate
bcrypt · Adjustable cost factor · Random salt · One-way hash
Generate OWASP-compliant bcrypt hashes for secure password storage. Cost factor 12 recommended, benchmark to confirm timing on your server. Hash anatomy view shows exactly what each part of the bcrypt string means.
What is Bcrypt?
Bcrypt is a password hashing algorithm designed by Niels Provos and David Mazières in 1999. Unlike general-purpose hash functions (MD5, SHA-256), bcrypt is intentionally computationally expensive. It uses a configurable cost factor to ensure hashing always takes a significant amount of time — making brute-force and dictionary attacks impractical even with modern GPU hardware.
Choosing the Right Cost Factor
The cost factor (work factor) controls how slow bcrypt is. Cost 12 means 2^12 = 4,096 internal rounds. Each increment doubles the time. The OWASP recommendation is to target 100–300ms hashing time on your production server. Cost 12 is typically right for modern hardware — run the benchmark to find the right value for your specific server.
Frequently Asked Questions
What does OWASP say about bcrypt?
OWASP Password Storage Cheat Sheet recommends bcrypt with cost factor 10 as minimum. It prefers Argon2id for new systems but accepts bcrypt as a secure alternative. The key requirement is that hashing takes at least 100ms.
How do I implement bcrypt in a REST API?
Hash on registration: const hash = await bcrypt.hash(password, 12). Store hash in DB. On login: const match = await bcrypt.compare(inputPassword, storedHash). Return JWT only if match is true. Never return or log the hash.
Should I use bcrypt or Argon2 for new projects?
OWASP recommends Argon2id as first choice for new systems. Use bcrypt if your language/framework has better bcrypt support or if you need to maintain compatibility with existing hashes. Both are secure.
What is pepper and should I use it with bcrypt?
Pepper is a server-side secret added before hashing (unlike salt, it is not stored in the DB). It adds an extra layer — even with database access, attackers need the pepper to verify passwords. Store pepper in environment variables, not in the database.
How do I migrate from MD5 to bcrypt?
You cannot convert MD5 hashes to bcrypt without the original passwords. Instead: on each user login, verify with MD5, then immediately re-hash with bcrypt and update the database. After all active users have migrated, invalidate remaining MD5 accounts.