How does bcrypt work?

How bcrypt slows password cracking without changing the password itself

bcrypt is designed to make each password guess expensive. It does that by combining the password with a unique salt and then running a deliberately slow hashing process whose cost can be tuned. The hash result is deterministic for the same password and salt, but the work required to test guesses increases as the cost factor rises.

That design matters because modern attackers rarely rely on a single offline guess. They try large batches of candidate passwords, reuse stolen lists, and benchmark whatever hash function they recover. bcrypt does not prevent guessing, but it raises the computation cost enough that large-scale cracking becomes slower, more expensive, and less practical.

Why the salt and cost factor matter in real deployments

The salt ensures that two users with the same password do not end up with the same stored hash. That blocks rainbow table reuse and makes precomputed cracking far less effective. The cost factor, sometimes called the work factor, lets defenders increase hashing effort over time as hardware improves, which is why bcrypt remains useful even though it is an older design.

At a practical level, bcrypt is usually chosen for password storage rather than for general cryptographic hashing. It is intended for human-chosen secrets, where latency on login is acceptable and deliberate slowness is a benefit. It is not trying to be fast, and that is exactly the point.

When you compare password hashes across systems or across time, bcrypt also gives you an operational clue: the hash format itself carries the cost setting, so you can tell whether a stored password needs rehashing after a policy change. That makes migration easier than with many older hash schemes, because you can raise the work factor gradually without forcing every user to reset at once.

What bcrypt does not solve, and how defenders should use it

bcrypt protects stored passwords, but it does not protect weak passwords, reused passwords, phishing, session theft, or credential stuffing against live services. If an attacker already knows the password, a strong hash does not stop login. If the application stores the hash but also logs plaintext passwords, caches them, or exposes them elsewhere, bcrypt only covers one part of the problem.

For that reason, password hashing should be treated as one control in a larger authentication design. A strong hashing algorithm reduces offline cracking risk after a database exposure, but account protection still depends on password policy, rate limiting, MFA where appropriate, secure reset flows, and careful handling of any secrets used by the application itself. NHIMG’s Password Security and Password Manager Guide is a useful companion for the broader password policy decisions around storage, reuse, and migration away from weaker hashes.

Risk and Threat Considerations

bcrypt reduces the damage from password database theft, but the protection is only as strong as the chosen cost setting, password quality, and the rest of the authentication stack. If the cost is too low, modern hardware can test guesses quickly; if passwords are weak or reused, attackers may still recover accounts through offline cracking or live abuse even when the hash itself is sound.

Failure mechanism: Attackers exploit exposed password hashes by running offline dictionary, spraying, and brute-force workflows against the recovered hash material, with weak passwords and outdated cost settings making success more likely.

Impact: Successful cracking can lead to account takeover, lateral movement, and reuse of the recovered password on other services, especially when users recycle credentials.

Practitioner Guidance

What to verify: Confirm that password hashes are stored only as bcrypt hashes, that the cost factor matches current performance and latency targets, and that legacy hashes are being rehashed on successful login rather than left in place indefinitely.

Decision rule: If an account store contains unsalted hashes, fast hashes, or any password values outside the hashing pipeline, treat that as a migration and exposure problem first, not just a configuration detail.

Common mistake: Teams often treat bcrypt as a complete password security strategy when it is really one layer. Strong hashing helps after compromise, but it does not compensate for weak password reuse, poor reset flows, or missing monitoring around authentication abuse.

Practitioner takeaway: bcrypt is most effective when you use it to make offline cracking economically unattractive, then pair it with controls that reduce the chance of password exposure or reuse in the first place.

Related resources from NHI Mgmt Group

• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?