bcrypt Salt Rounds Explained: How to Choose

bcrypt Salt Rounds Explained: How to Choose

The salt rounds parameter controls bcrypt's cost. Higher is slower (safer); lower is faster (weaker). Here is how to choose.

What Salt Rounds Means

bcrypt.hash(password, N) runs the hash function 2^N times. N=10 means 1024 iterations. N=12 means 4096 iterations. Each increment doubles the work.

Time per Round

On a modern CPU:

• N=8: ~25ms
• N=10: ~100ms
• N=12: ~400ms
• N=14: ~1.6s

What to Pick

• N=10: good default for most apps. ~100ms per hash. Negligible UX impact at signup and login.
• N=12: for high-security apps. ~400ms. Noticeable but acceptable.
• N=14+: too slow for most apps. Use only if you have a real threat model that demands it.

Tradeoffs

Higher rounds mean:

• Slower signup and login for users.
• More CPU per request.
• Harder for attackers to brute-force.

Lower rounds mean:

• Faster for users.
• Less CPU per request.
• Easier for attackers to brute-force.

When to Rehash

As hardware gets faster, your hash gets weaker. Rehash passwords with a higher round count when:

• You migrate to a new algorithm.
• You decide to bump the rounds (e.g., from 10 to 12).

On next login, verify the old hash, then rehash with the new cost and save. Store the cost with the hash (bcrypt does this automatically in the hash string).

Reading the Cost From a Hash

A bcrypt hash looks like $2b$10$.... The 10 is the cost. You can read it to know what cost was used:

const cost = hash.split('$')[2];

Use this to detect old hashes that need rehashing.

The Takeaway

bcrypt salt rounds control the cost. Use 10 for most apps (~100ms per hash). Use 12 for high-security apps (~400ms). Each increment doubles the work. Rehash with a higher cost on next login when hardware gets faster or you migrate.