Bcrypt Generator

Bcrypt & password-hashing education hub

What is bcrypt?

bcrypt is an adaptive password-hashing function designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. Unlike general-purpose hashes such as MD5 or SHA-256, bcrypt is built specifically for storing passwords: it is deliberately slow, it salts every password automatically, and its cost can be increased over time as hardware gets faster.

A bcrypt hash is a single 60-character string that packs everything needed to verify a password: the algorithm version, the cost factor, the random salt and the resulting digest. That self-contained design is why bcrypt is so popular — you store one string per user and the verify function reads the parameters straight back out of it.

How does bcrypt work?

bcrypt runs an “expensive key setup” version of Blowfish called EksBlowfish. It first initialises Blowfish’s key schedule using both the password and the salt, then repeats that key-setup step 2^cost times. This iterated, state-mixing process is what makes bcrypt slow on purpose — and the slowness is the security feature.

After the key-setup loop, bcrypt encrypts the constant text “OrpheanBeholderScryDoubt” 64 times with the resulting Blowfish state. The final ciphertext is the 184-bit digest you see at the end of the hash. Because the salt feeds into the key schedule, the same password produces a completely different hash every time.

The format is $version$cost$saltdigest — for example $2b$12$ followed by a 22-character base-64 salt and a 31-character base-64 digest. To verify a password later, bcrypt re-reads the version, cost and salt from the stored hash, recomputes the digest, and compares it in constant time.

What is a salt and why does it matter?

A salt is random data combined with a password before hashing. Its job is to guarantee that two users with the same password get two different hashes. Without salts, attackers can use precomputed “rainbow tables” to reverse millions of common hashes instantly, and they can see at a glance which users share a password.

bcrypt generates a fresh 128-bit salt for every hash and embeds it directly in the output, so you never manage salts yourself. That is a key advantage over rolling your own scheme: there is no separate salt column to forget, and you cannot accidentally reuse a salt across users.

What is the cost (work) factor?

The cost factor — also called the work factor or rounds — controls how many times bcrypt repeats its key-setup step. The number of iterations is 2^cost, so a cost of 10 means 1,024 rounds, 12 means 4,096, and 14 means 16,384. Each increment doubles the time to compute a hash.

This is what makes bcrypt “adaptive”: as computers get faster you simply raise the cost. The right value is the highest one your servers can tolerate at login time — a common target is roughly 250–500 milliseconds per hash. OWASP currently recommends a minimum cost of 10, and 12 is a sensible default for most web applications in 2024 onwards.

Why password hashing matters

Databases get breached. When they do, the difference between a minor incident and a catastrophe is how passwords were stored. If you stored plaintext, every account is compromised immediately — and because people reuse passwords, the damage spreads to their email, banking and work accounts.

Hashing with a slow, salted function like bcrypt means an attacker who steals your database still has to crack each password individually, one expensive guess at a time. Strong, unique passwords behind a high cost factor can take centuries to recover. Password hashing is the single most important control for protecting your users after a breach.

Encryption vs hashing — what’s the difference?

Encryption is reversible: with the key, ciphertext can be turned back into the original data. That is exactly what you do not want for passwords, because the key becomes a single point of failure — steal the key and you steal every password.

Hashing is one-way: there is no key and no way to reverse a good hash back to the input. To check a password you hash the attempt and compare. Passwords should always be hashed (with bcrypt, Argon2id, scrypt or PBKDF2), never encrypted. Encryption is for data you need to read back, like API tokens or personal data at rest.

How password storage actually works

At registration, the server hashes the chosen password with bcrypt and stores only the resulting 60-character hash — never the plaintext. At login, the server hashes the submitted password with the same salt and cost (both read from the stored hash) and uses a constant-time comparison to decide whether they match.

Crucially, the server never needs to know the original password again. “Forgot password” flows therefore reset the password via a one-time link rather than emailing it back — if a site can email you your existing password, it is storing it insecurely.

Why MD5 is unsafe for passwords

MD5 is a fast, general-purpose hash that is also cryptographically broken: practical collision attacks have existed for years. But even setting collisions aside, MD5’s real problem for passwords is speed. A single GPU can compute tens of billions of MD5 hashes per second, so an attacker can try every common password and dictionary word almost instantly.

MD5 also has no built-in salt, so identical passwords share a hash and rainbow tables apply directly. Never use MD5 — salted or not — to store passwords.

Why SHA-256 alone is unsafe for passwords

SHA-256 is a strong, modern hash — for file integrity and digital signatures. The problem is the same as MD5’s: it is designed to be fast. Modern GPUs and ASICs compute billions of SHA-256 hashes per second, which is excellent for a blockchain but terrible for password storage, where you want hashing to be slow.

A bare SHA-256 of a password, even with a salt, is crackable at enormous speed. Password storage needs a deliberately slow, salted, tunable function. That is precisely what bcrypt, Argon2id, scrypt and PBKDF2 provide — they wrap fast primitives in thousands or millions of iterations and, in the modern designs, large memory requirements.

Why bcrypt is recommended

bcrypt has been protecting passwords for over two decades and is supported by mature, audited libraries in virtually every language. It salts automatically, it is adaptive through the cost factor, and it resists GPU acceleration better than plain hashes because its algorithm needs frequent, unpredictable memory access during key setup.

It is not the newest design — Argon2id, the winner of the 2015 Password Hashing Competition, is more memory-hard and is OWASP’s first recommendation for new systems. But bcrypt remains on every modern best-practice list. If your stack already uses it, a healthy cost factor keeps you secure; if you are building something new and have no FIPS requirement, consider Argon2id, with bcrypt as an excellent fallback.