Bcrypt Generator & Checker

bcrypt was designed in 1999 by Niels Provos and David Mazières for OpenBSD, specifically to replace the then-common crypt(3) DES-based password hashing that had become broken by Moore's Law. Twenty-six years later it remains the most-deployed password hashing scheme on the web — used by Laravel, Django, Rails, Express, every WordPress install, every major SaaS authentication stack. Its central insight: make the hash function deliberately slow, then make the slowness tunable so it can scale with hardware improvements. Hash a million passwords at cost 4? Fast. Hash a million passwords at cost 14? You're paying a thousand seconds per hash. An attacker brute-forcing leaked hashes pays the same cost — but you only do it once per login, while the attacker does it billions of times.

How bcrypt actually works

The construction is based on a modified Blowfish cipher. The "EksBlowfish" key schedule is run 2^cost times with the password and a 16-byte salt as input, producing a stretched key. That key is then used to encrypt the literal string "OrpheanBeholderScryDoubt" 64 times, and the result is encoded in bcrypt's custom radix-64 alphabet alongside the cost and salt. The output is a single 60-character string starting with $2a$ or $2b$ (the variant identifier), followed by the cost, salt, and hash. Verifying a password is the same operation — extract cost and salt from the candidate hash, recompute, and compare. The cost factor is the binary log of the iteration count; cost 10 means 2^10 = 1,024 iterations, cost 12 means 4,096 iterations.

The 72-byte limit

bcrypt has a quirk that catches developers off guard: it silently truncates passwords longer than 72 bytes. A user setting an 80-character passphrase ends up with the first 72 bytes hashed — the last 8 don't affect the hash. Two passwords that share the first 72 bytes produce identical hashes. This is a property of the underlying Blowfish key schedule. The common workaround is to pre-hash long passwords with SHA-256 or SHA-512 before passing them to bcrypt, producing a fixed 32 or 64-byte input. Modern libraries like Argon2 do not have this limit.

MAS and BNM password-storage guidance

Singapore's MAS Technology Risk Management Guidelines and Malaysia's BNM RMiT guidelines both reference password storage requirements without prescribing a specific algorithm — they require "use of strong, salted, adaptive hashing." bcrypt at cost ≥10, Argon2id with reasonable parameters, and scrypt with appropriate memory factor all satisfy this. What does NOT satisfy: plain SHA-256, MD5, SHA-1, or any unsalted hash. Both regulators audit-flag any ASEAN-licensed fintech caught using MD5 or unsalted SHA-256 for password storage. bcrypt is the path-of-least-resistance compliant choice; Argon2id is the more-modern alternative recommended for new builds.

bcrypt vs Argon2 vs scrypt — picking in 2026

If you're building a new system today: Argon2id with 64MB memory cost and t=3 iterations is the Password Hashing Competition winner (2015) and the recommended modern default. scrypt (2009) was a step between bcrypt and Argon2 — better memory-hardness than bcrypt but harder to tune than Argon2. bcrypt remains the safest "boring" choice — it's been deployed for 26 years without a major break, every language has a mature implementation, and the cost-tuning model is well-understood. If your stack has Argon2 readily available (PHP 7.2+, .NET 5+, Node.js Argon2 package), use it. If not, bcrypt at cost 12 is still defensible for new code in 2026.