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 - Free Online Secure Hashing Tool

Using This Memory-Hard Hashing Tool

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.

Bcrypt Password Generator provides an interface for intentionally slow password-hashing functions that resist brute-force attacks. Both bcrypt and scrypt are industry standards; bcrypt's strength is widely understood across every major language, while scrypt adds memory-hardness - it requires large amounts of RAM as well as CPU time - making it significantly more expensive to attack with specialized hardware. This scrypt hash tool ensures all processing is done in your browser; no passwords leave your device.

Bcrypt vs Scrypt: Choosing the Right Algorithm

Use bcrypt when you need broad library support and predictable hardware requirements. This password checker 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. The bcrypt cost factor and scrypt's memory requirement make them both substantially harder to parallelize than simple hashes. Argon2 alternative is also a common discussion point in modern security audits.

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.

For non-password needs, check our All Hashes tool or use AES Cipher for symmetric encryption. Secure your application correctly and bookmark this Bcrypt Password Generator for your next security audit.

Bcrypt Password Generator online

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