What is bcrypt?

Bcrypt is a password hashing function designed by Niels Provos and David Mazières in 1999, specifically built to resist brute-force attacks. Unlike fast cryptographic hashes (MD5, SHA-256) that crack in seconds with modern GPUs, bcrypt is intentionally slow and uses an adaptive cost factor — you can increase work factor as hardware gets faster, keeping passwords secure against future attacks. Used by virtually every major password storage system since the 2000s: Django, Laravel, Rails, Express.js, WordPress (option), countless other frameworks. Each bcrypt hash includes the algorithm version, cost factor, salt, and hash — all self-contained for easy verification.

How to use this tool

1. Enter the password — The plain-text password to hash.
2. Set cost factor (4-14) — Higher = slower = more secure. 10-12 is modern default.
3. Generate hash — Tool runs bcrypt algorithm with random salt.
4. Copy the bcrypt hash — Format: $2a$10$<22-char salt><31-char hash>
5. Store hash in database — Never store plain password — only the bcrypt hash.

Bcrypt cost factor explained

Cost is a power of 2 — each +1 DOUBLES the work:

Hash format:

$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
  │  │  │
  │  │  └─ salt (22 chars) + hash (31 chars)
  │  └─── cost factor (10 = 2^10 = 1024 iterations)
  └────── algorithm version (2a, 2b, or 2y)

Examples

• User signup: User enters password → bcrypt hash → store hash in database
• User login: User enters password → bcrypt compare with stored hash → allow login
• Password reset: New password → new bcrypt hash → replace old hash
• Audit log: 'User john bcrypt verified at 2024-05-27 10:30 UTC'
• Hash migration: Old MD5 passwords → bcrypt on next login (verify with MD5, replace with bcrypt)
• Cost adjustment: Site started with cost 10; rehash to cost 12 as users login (more secure)

Tips & best practices

• Cost 10-12 is current best practice (2024)
• NEVER store plain passwords — always store bcrypt hashes only
• Use language libraries (bcryptjs, passlib, bcrypt in Node) — don't implement bcrypt from scratch
• Compare bcrypt hashes with bcrypt.compare() not string equality — constant-time comparison built-in
• Salt is generated automatically — don't reuse salts across users
• If cost is too high (login >1 second), users complain — balance security vs UX
• On password change, rehash with current cost factor — gradually upgrades older hashes

Limitations & notes

bcrypt has a 72-character password limit — longer passwords are truncated to 72 bytes (silently in some implementations, error in others). For very long passphrases, pre-hash with SHA-256 first then bcrypt the result. bcrypt is for PASSWORDS only — for API tokens, file checksums, or general hashing, use SHA-256 or HMAC instead. bcrypt isn't the only modern option — Argon2 and scrypt are newer alternatives with similar goals.

Frequently Asked Questions

Why is bcrypt slow?

Intentional. Fast hashes (MD5, SHA-256) crack passwords at billions/second on GPUs. Bcrypt takes ~100ms per hash — attackers can only try ~10/second. With strong passwords, brute force becomes infeasible.

What cost factor should I use?

10 for most sites (2024). 12 for high-security applications. Aim for <500ms per hash to maintain user experience while resisting attacks.

Is bcrypt better than SHA-256 for passwords?

Yes — vastly. SHA-256 cracks at billions/sec on GPUs. Bcrypt is intentionally slow with configurable cost. Use bcrypt (or Argon2) for passwords, SHA-256 for general hashing.

What's the 72-character limit about?

Bcrypt internals only use the first 72 bytes of input. Longer passwords get truncated. For 72+ char passphrases, hash with SHA-256 first, then bcrypt. Most users don't hit this limit.

Should I use bcrypt or Argon2?

Argon2 (won 2015 Password Hashing Competition) is newer and arguably better. Memory-hard (resists ASIC attacks). For new systems, prefer Argon2id. For existing bcrypt deployments, bcrypt is still fine.

How do I verify a password against bcrypt hash?

Use library's compare function: bcrypt.compare(password, hash). This re-runs bcrypt with the stored salt and compares results. Always use the library function — never string-compare hashes.

Can bcrypt hashes be cracked?

Yes, given enough time and weak passwords. Hashcat with GPU can attempt billions of guesses but bcrypt at cost 10 limits to ~10/sec. Strong password (16+ chars random) is uncrackable in practical time.

Related tools

HMAC Generator · Hash Generator · Password Generator