How Bcrypt Works: Salts, Rounds, and Secure Password Storage

How Bcrypt Works: Salts, Rounds, and Secure Password Storage

Password storage is a core security concern for any application that authenticates users. Bcrypt is a widely used password-hashing function designed to store passwords safely by making brute-force attacks expensive and by protecting against precomputed attacks. This article explains how bcrypt works, what salts and rounds are, and how to use bcrypt correctly to secure password storage.

What bcrypt is

Bcrypt is a password-hashing algorithm based on the Blowfish cipher and introduced by Niels Provos and David Mazières. Its goals are to:

• Produce a one-way, non-reversible hash of a password.
• Be slow and tunable so that hashing costs can scale with hardware improvements.
• Include a built-in salt mechanism to prevent identical passwords from producing identical hashes.

Salts: why they matter

A salt is a random value unique to each password hash. Salts are critical because:

• They ensure that the same password hashed twice yields different outputs.
• They thwart use of precomputed hash tables and rainbow tables.
• They force attackers to attack each password separately rather than cracking many at once.

How bcrypt uses salts:

• Bcrypt generates a random 128-bit salt for each password.
• The salt is stored alongside the resulting hash (typically embedded in the bcrypt string format).
• During verification, the stored salt is extracted and used to recompute the hash for comparison.

Rounds (cost factor): tuning work factor for security

Bcrypt includes a configurable “cost” parameter (often called rounds or work factor). This determines how computationally expensive the hash function is:

• The cost is an exponent: number of internal iterations = 2^cost.
• Higher cost increases the time required to compute a hash, slowing attackers trying many guesses.
• As hardware improves (faster CPUs/GPUs), increase the cost to maintain resistance against brute-force attacks.

Practical guidance:

• Choose the highest cost that still provides acceptable authentication latency (commonly 100–500 ms per hash on your servers).
• Regularly revisit the cost as hardware and performance expectations change.
• When users authenticate, you can detect if the stored bcrypt cost is lower than your current standard and re-hash the password with the new cost after successful login.

Bcrypt hash format

Bcrypt hashes are typically stored as a single string that encodes algorithm, cost, salt, and hash. Example format: \(2b\)12\(<22-character-salt><31-character-hash></p> <ul> <li>\)2b$: bcrypt version identifier (variants include 2a, 2b, 2y).

How bcrypt hashing and verification work (high-level)

1. Generate a secure, random salt.
2. Combine the password and salt and run the bcrypt algorithm with the chosen cost to produce the hash.
3. Store the full bcrypt string (version, cost, salt, hash) in your user database.
4. To verify, extract version, cost, and salt from the stored string, run bcrypt on the presented password, and compare the result to the stored hash in constant time.

Common implementation considerations

• Use well-maintained, vetted libraries instead of implementing bcrypt yourself.
• Always use a cryptographically secure random generator for salts.
• Never store plaintext passwords or reversible encryption of passwords.
• Compare hashes using constant-time comparison to avoid timing attacks.
• Don’t set the cost so high that legitimate users experience long delays or your service becomes unavailable.
• Consider account lockout or rate-limiting to slow online guessing attacks in addition to strong hashing.

Migration and algorithm upgrades

• If you need to move from an older algorithm (e.g., MD5, SHA1) to bcrypt, verify users’ passwords at login and re-hash with bcrypt on successful authentication.
• To upgrade bcrypt cost, re-hash at login when you detect a lower cost in the stored hash.
• For future-proofing, design your storage to include an algorithm identifier so you can migrate to stronger algorithms (e.g., Argon2) later.

When to consider alternatives

Bcrypt remains secure and widely supported, but newer memory-hard algorithms like Argon2 offer stronger resistance against GPU/ASIC attacks because they require substantial memory as well as CPU time. Consider Argon2 if:

• You need state-of-the-art resistance to specialized attack hardware.
• Your environment supports allocating memory and configuring parameters safely.

Summary

• Bcrypt provides secure, salted, tunable password hashing.
• Salts prevent precomputed attacks; the cost factor slows brute-force attempts.
• Use vetted libraries, pick an appropriate cost, store the full bcrypt string, and upgrade parameters over time.
• Combine bcrypt with rate-limiting and good account-security practices for robust protection.

Code examples, configuration, and library recommendations can be provided for specific languages if you want—tell me which language you’re using.