bcrypt - Time-Tested Password Hashing

About 2 min read

bcrypt is a password hashing function based on the Blowfish cipher, designed in 1999 by Niels Provos and David Mazières. Its defining feature is a design that lets you exponentially increase the computational cost by adjusting the cost factor (work factor), allowing the security strength to be raised in step with improvements in hardware performance. It has been widely used for more than 25 years, and even now that Argon2 has appeared, it remains a highly reliable algorithm that ranks second on the OWASP recommendation list.

Historical Background

Before bcrypt appeared, Unix systems used the DES-based crypt function for password hashing. However, by the late 1990s the speedup of CPUs made the computational cost of crypt insufficient, and dictionary attacks and brute-force attacks had become realistic threats. Provos and Mazières designed bcrypt as part of the OpenBSD project and established the concept of an adaptive hash function that "remains secure even on future hardware." This design philosophy was later inherited by scrypt and Argon2.

How the Cost Factor Works

bcrypt's cost factor is specified as an integer from 4 to 31, and internally it performs 2-to-the-cost-power iterations. Increasing the cost factor by 1 roughly doubles the computation time.

In practice, you choose the largest cost factor whose login-processing latency stays within an acceptable range (typically 250 ms - 1 second). It is recommended to periodically review and raise the cost factor in line with the CPU performance of the server.

Automatic Salt Generation and Storage Format

bcrypt automatically generates a 128-bit salt and stores it together with the hash value as a single string. A major practical advantage is that developers do not need to separately implement salt generation or management.

Comparison with Argon2

The biggest difference between bcrypt and Argon2 is whether they are memory-hard. bcrypt is a CPU-bound function and does not demand large amounts of memory for its computation. As a result, it offers less resistance than Argon2 against attacks that run hash computations in parallel on GPUs with thousands of cores. For new systems, Argon2id is the first choice, but for systems where bcrypt is already in use, there is no need to migrate immediately as long as the cost factor is set appropriately. When migrating, the common approach is to re-hash on the next login. The overall design of password storage is explained in the secure password management guide.

Caveats of the 72-Byte Limit

bcrypt has a limitation in that the input password is truncated at 72 bytes. In UTF-8 encoding, a single Japanese character consumes 3 bytes, so for a password consisting only of Japanese characters the effective upper limit is 24 characters. With a mix of alphanumeric characters, up to 72 characters are valid, but anything beyond that is ignored. To work around this limit, there is a technique of pre-hashing the password with SHA-256 before passing it to bcrypt, but it requires careful implementation because of pitfalls such as the null-byte problem. Take this limit into account when designing a password policy.password security books on Amazon to learn the implementation details.

Common Misconceptions

The perception that "bcrypt is old, so it is dangerous" is not accurate. No fatal vulnerability has been found in bcrypt itself, and operated with an appropriate cost factor (12 or higher) it provides sufficient security even as of 2025. What becomes a problem is when the cost factor is too low (below 10) or when an old implementation containing library bugs continues to be used. The historical evolution of password hashing is also introduced in the article on the history and culture of passwords. For the basics of cryptography, see the basics of encryption.