Bcrypt Hash Generator

How to use Bcrypt Hash Generator

1. Enter the password to hash.
2. Choose a cost factor — 12 is a reasonable default on current hardware.
3. Generate, and store the entire output string in one column.
4. The salt is generated randomly and embedded in the output — do not store one separately.
5. Each cost increment doubles the computation time; aim for 200–500ms on your production hardware.
6. bcrypt truncates input at 72 bytes, which matters if you accept long passphrases.

Why a password hash has to be slow

SHA-256 is designed to be fast, and a GPU computes billions a second — which is the whole problem when the input is a human-chosen password from a list of a few hundred million. bcrypt is deliberately slow, and the cost factor controls how slow. Each increment doubles the work: cost 10 is roughly 100ms, cost 12 about 400ms, cost 14 about 1.6 seconds. That is imperceptible for one login and catastrophic for an attacker trying a dictionary, which is precisely the asymmetry you are buying.

Reading the hash string

A bcrypt hash looks like $2b$12$R9h/cIPz0gi… and is self-describing. $2b$ is the algorithm version, 12 is the cost factor, the next 22 characters are the salt, and the rest is the digest. Everything needed to verify a password is in that one string, which is why you store a single column and never a separate salt. It also means the cost is recorded per hash, so you can raise it for new passwords and rehash old ones on next login without breaking anyone.

The salt is the reason rainbow tables fail

Every hash gets a fresh random salt, so the same password hashed twice produces two completely different strings. That defeats precomputed tables outright — an attacker cannot build one table and test it against every account, they must attack each password separately. It also means two users with the identical password have no visible relationship in your database, which unsalted hashes leak immediately.

Where bcrypt now sits

It has one real limitation: input is truncated at 72 bytes, so a very long passphrase is silently cut short — which matters if you allow long inputs and assume they all count. Argon2id is the current recommendation from OWASP and the winner of the Password Hashing Competition, because it is memory-hard as well as slow, which resists custom hardware in a way bcrypt does not. scrypt is a reasonable middle ground. bcrypt remains entirely acceptable and is not broken — if you already use it at a sensible cost, that is not the weak point in your system.