Bcrypt is a password hashing function designed by Niels Provos and David Mazières in 1999. It incorporates a salt to protect against rainbow tables and is deliberately slow (configurable via cost factor) to resist brute-force attacks.

What cost factor should I use?

A cost of 10 is a widely used default. Cost 12 is recommended for new applications in 2024. Higher costs increase security but also increase hashing time. The hashing time should target 100–300ms on your production hardware.

Bcrypt Password Generator & Checker

How to Use bcrypt-scrypt

Enter your plaintext password in the input field.
Select bcrypt or scrypt as the algorithm.
Adjust cost parameters — cost factor for bcrypt, N/r/p for scrypt.
Click Hash and copy the output; use Verify to check a password against an existing hash.

Both bcrypt and scrypt are intentionally slow password-hashing functions that resist brute-force attacks. Bcrypt's strength is widely understood and implemented across every major language. Scrypt adds memory-hardness — it requires large amounts of RAM as well as CPU time — making it significantly more expensive to attack with ASICs or FPGAs. All processing is done in your browser; no passwords leave your device.

Bcrypt vs Scrypt: When to Use Which

Use bcrypt when you need broad library support and predictable hardware requirements. It is available in virtually every backend language and has a 20-year track record. Use scrypt when you are operating in a high-threat environment and can tolerate higher memory consumption per hash. Scrypt's memory requirement makes it substantially harder to parallelize with GPUs or custom hardware. Argon2 is a third option that combines time and memory hardness with better parameter control.

Bcrypt: cost factor 4–31, random salt, 72-byte input limit
Scrypt: configurable N (CPU/memory), r (block size), p (parallelization)
Both include automatic salting — no two hashes of the same password are identical
Verify mode compares plaintext to stored hash without exposing the salt

Frequently Asked Questions

What makes scrypt "memory-hard"?

Scrypt's algorithm requires large contiguous blocks of memory (determined by the N and r parameters). An attacker who tries to use thousands of GPU cores cannot share that memory — each cracking attempt needs its own RAM allocation, drastically reducing parallelism.

What are good scrypt parameters for web apps?

The Node.js crypto module defaults are N=16384, r=8, p=1. OWASP recommends N=65536, r=8, p=1 as a minimum for high-security contexts. Benchmark on your target hardware to ensure response time stays under 1 second.

Is there a maximum password length for scrypt?

Unlike bcrypt (which truncates at 72 bytes), scrypt accepts arbitrary-length input through its underlying PBKDF2-SHA256 step. There is no practical length limit.

Should I migrate from bcrypt to scrypt?

Only if your threat model requires memory-hardness. Bcrypt at cost 12 is still considered secure for most applications. Migrating requires a transition plan: re-hash existing passwords on next login.

See the All Hashes tool for non-password hashing, and the AES Cipher for symmetric encryption.

Bcrypt Password Generator & Checker online

Generate bcrypt password hashes and verify them — runs entirely in your browser