Bcrypt Hash Generator

Hashing passwords with bcrypt

Bcrypt is a password hashing function built for one job: storing passwords so that a database leak does not instantly reveal them. You feed it a password and it returns a hash you can save. Later you verify a login by hashing the attempt and comparing. Crucially, you never store the password itself, only the bcrypt output.

Slow on purpose, and salted automatically

Here is what sets bcrypt apart from a fast hash like SHA-256. SHA is designed to be fast, which is great for checksums but terrible for passwords, because an attacker can test billions of guesses per second. Bcrypt is deliberately slow, and its speed is tunable through a cost factor (also called work factor or rounds). A cost of 10 means 2^10 iterations; raising it to 12 makes hashing roughly four times slower, which barely affects a real login but massively slows brute force. Bcrypt also generates a random salt automatically and embeds it in the output, so two users with the same password get different hashes.

Example

Hashing hunter2 at cost 10 produces something like:

$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

Reading the structure:

$2b$   algorithm version
$10$   cost factor (2^10 rounds)
N9qo...22 chars  the salt
IjZA...the rest  the actual hash

FAQ

Why is the hash different every time? The random salt changes each run, so identical passwords never produce identical hashes. Verification still works because the salt is stored inside the hash.

Which cost factor should I use? Pick the highest value where a single hash still completes in a fraction of a second on your server, commonly 10 to 12. Revisit it as hardware gets faster.

Is there a length limit? Yes. Bcrypt only uses the first 72 bytes of the input, so very long passphrases are truncated. Pre-hashing with SHA-256 is a common workaround for that specific limit.