Bcrypt Cost 10 vs 12: Performance Trade-off

Compare bcrypt cost factor 10 and 12 in terms of hashing speed, security margin, and server load. Understand when to choose each value and how to benchmark on your own production infrastructure.

Salt Rounds

Detailed Explanation

Bcrypt Cost 10 vs 12: Performance Trade-off

Cost 10 and cost 12 are the two most commonly used bcrypt cost factors. The difference between them is a 4x increase in computation — cost 10 runs 1,024 iterations while cost 12 runs 4,096. This section breaks down the practical implications.

Performance Comparison

Metric Cost 10 Cost 12
Iterations 1,024 4,096
Hash time (typical) ~4 ms ~15 ms
Hashes/second/core ~250 ~65
Login overhead Negligible Still negligible

For a web application handling login requests, even cost 12 adds only ~15 ms to the authentication flow — imperceptible to users.

Security Comparison

The real difference shows up in attack scenarios. Assume an attacker has a GPU rig capable of 10,000 bcrypt hashes per second at cost 10:

  • Cost 10: 10,000 attempts/second → 864 million attempts/day
  • Cost 12: 2,500 attempts/second → 216 million attempts/day

Cost 12 reduces the attacker’s throughput by 75%, making brute-force attacks 4x more expensive.

When to Use Cost 10

  • Legacy systems where changing the cost factor requires extensive testing
  • High-throughput authentication services processing thousands of logins per second
  • Applications running on constrained hardware (embedded systems, cheap VPS instances)
  • During development and testing (faster test suite execution)

When to Use Cost 12

  • New applications with no legacy constraints
  • Any application where login latency of 15–30 ms is acceptable (nearly all web apps)
  • Systems storing sensitive data (financial, healthcare, government)
  • When you want headroom before the next cost increase

Server Load Considerations

For a web server handling 100 concurrent logins:

  • Cost 10: 100 × 4 ms = 400 ms of total CPU time
  • Cost 12: 100 × 15 ms = 1,500 ms of total CPU time

Both are well within acceptable limits for modern multi-core servers. However, if your application runs on a single-core instance or handles extreme login spikes (e.g., event ticketing), cost 10 may be the pragmatic choice.

Migration Strategy

If you are currently using cost 10 and want to move to cost 12, use the rehash-on-login pattern:

const stored = await db.getHash(userId);
if (bcrypt.compareSync(password, stored)) {
  const rounds = parseInt(stored.split('$')[2], 10);
  if (rounds < 12) {
    const newHash = bcrypt.hashSync(password, 12);
    await db.updateHash(userId, newHash);
  }
  // proceed with login
}

This upgrades hashes transparently as users log in.

Use Case

The cost 10 vs 12 decision comes up in every project planning session for authentication systems. DevOps teams need to understand the server load implications, security engineers need to quantify the brute-force resistance difference, and product managers need to know the user-facing impact. Having concrete numbers helps teams make an informed decision rather than defaulting to the library’s default.

Try It — Bcrypt Generator

Open full tool