Bcrypt Toolkit

Bcrypt is a password hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher. It is a one-way function — once a password is hashed, the original text cannot be recovered from the hash. Bcrypt is widely used for securely storing passwords in databases.

The cost factor (also called work factor or strength) controls how computationally expensive the hashing process is. Each increment doubles the number of iterations. A cost factor of 12 means 2¹² = 4,096 iterations. Higher cost factors make brute-force attacks significantly harder, but also increase the time required to hash a password.

Bcrypt automatically generates a random salt for each hash operation. The salt is embedded in the resulting hash string. This means two hashes of the same password will look completely different, which prevents rainbow table attacks. Verification works by extracting the salt from the stored hash and re-hashing the input for comparison.

No. Bcrypt is a one-way hashing function, not encryption. There is no decryption key and no algorithm to reverse the process. Verification is performed by hashing the input text with the same salt and comparing the result — not by decrypting the stored hash.

The recommended starting point is 12. You should benchmark your server and choose the highest cost factor that keeps hashing time under an acceptable threshold (typically 100–300 ms for interactive logins). As hardware improves over time, consider increasing the cost factor periodically.

• 4–7: Low cost — for testing only
• 8–9: Moderate cost
• 10–11: Good security
• 12–13: High security — recommended starting point
• 14–16: Very high CPU usage

Yes. Bcrypt is specifically designed for password hashing and is considered a strong choice for this purpose. It is resistant to brute-force attacks due to its adjustable cost factor, and its built-in salting prevents precomputed attacks. Other modern alternatives include Argon2 and scrypt.

Bcrypt is based on the Blowfish cipher, which has an internal key schedule limited to 72 bytes (576 bits). Any input beyond 72 bytes is silently truncated. This means two passwords that share the same first 72 bytes will produce the same hash. If you need to hash longer inputs, consider pre-hashing with SHA-256 before passing to bcrypt, or use Argon2 which has no such limitation.

This tool is intended for learning, testing, and development purposes. While your input is not stored or logged, you should avoid entering real production passwords or sensitive credentials into any public web utility. For production use, integrate bcrypt directly into your application using a trusted library.