Category: Passwords & Hashing

bcrypt

Simply put

bcrypt is a method for scrambling passwords before they are stored so that the original password cannot be easily recovered. It is deliberately slow to compute, which makes it harder for attackers to guess passwords by trying many combinations. It also mixes in random data, called a salt, so that identical passwords do not produce identical stored values.

Formal definition

bcrypt is a password-hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher and presented at USENIX in 1999. It is a one-way, deliberately computationally expensive function that incorporates a per-password salt and a configurable cost (work) factor, allowing the computational effort to be increased over time as hardware improves; this design raises the cost of brute-force and dictionary attacks. bcrypt addresses secure storage of password credentials rather than authentication protocol flows or authorization decisions, and it is a hashing scheme, not an encryption scheme, the stored output is not intended to be reversed. Specific implementation details such as maximum input length handling and output encoding vary by library and are out of scope for this entry.

Why it matters

Password databases remain one of the highest-value targets in any breach, and how credentials are stored determines whether a database compromise becomes a catastrophic account takeover event or a contained incident. Storing passwords in plaintext, or with fast general-purpose hashes, allows an attacker who exfiltrates a credential store to recover large numbers of passwords through offline brute-force and dictionary attacks. bcrypt was designed specifically to raise the cost of these offline attacks by being deliberately slow to compute and by incorporating a per-password salt, so that identical passwords do not produce identical stored values and precomputed lookup tables become ineffective.

A key property that keeps bcrypt relevant is its configurable cost (work) factor, which lets operators increase the computational effort required per hash as hardware improves over time. This means a deployment can be tuned to remain expensive for attackers even years after initial rollout, rather than being fixed at a speed that becomes trivially cheap to attack. For IAM engineers and security architects responsible for credential storage, choosing and maintaining an appropriately costed password-hashing scheme is a foundational control, and bcrypt is one of the widely recommended options for this purpose.

It is important to keep bcrypt's scope in perspective: it protects credentials at rest in a store, but it does not authenticate users, make authorization decisions, or protect credentials in transit. It is a defense-in-depth measure that reduces the damage of a database compromise; it does not prevent the compromise itself, and it should be paired with other controls such as MFA and monitoring.

Who it's relevant to

IAM Engineers and Application Developers

Engineers building or maintaining systems that store user passwords need to select a deliberately slow, salted password-hashing function and configure its cost factor appropriately for their environment. bcrypt is a commonly recommended choice for this, and understanding that it is one-way and non-reversible is essential to implementing correct storage and verification flows.

Security Architects

Architects designing credential-storage controls should treat password hashing as a defense-in-depth measure that limits the impact of a database compromise. bcrypt's configurable cost factor is relevant when planning how a system will remain resistant to offline brute-force and dictionary attacks as hardware improves over time.

Compliance Officers and Auditors

Those assessing whether credentials are stored securely need to verify that passwords are protected with a salted, computationally expensive, one-way hashing scheme rather than plaintext or fast general-purpose hashes. bcrypt is one of the schemes typically encountered when reviewing such controls, though the appropriate cost setting depends on deployment context.

Inside bcrypt

Adaptive work factor (cost parameter)

A configurable cost value that controls how many hashing iterations bcrypt performs. Increasing it raises computational effort per hash, allowing the algorithm to remain resistant to brute-force attacks as hardware improves over time.

Built-in salt

bcrypt generates and incorporates a per-hash salt automatically, storing it within the output string. This defeats precomputed lookup (rainbow table) attacks without requiring the implementer to manage salts separately.

Self-contained output format

The resulting hash string typically encodes the algorithm identifier, the cost factor, the salt, and the derived hash together, so verification does not require storing these components separately.

Blowfish-based key schedule

bcrypt derives from the Blowfish cipher's expensive key setup, which is the source of its deliberate slowness and tunable cost.

One-way password hashing purpose

bcrypt is designed for storing password verifiers, not for general-purpose encryption or fast hashing. It is a one-way function intended to make offline cracking expensive rather than to allow recovery of the original input.

Common questions

Answers to the questions practitioners most commonly ask about bcrypt.

Is bcrypt an encryption algorithm?

No. Despite the '-crypt' in its name, bcrypt is a password-hashing function, not an encryption algorithm. Encryption is reversible with a key, whereas bcrypt produces a one-way hash that cannot be decrypted back to the original password. It is designed for verifying passwords by re-hashing a candidate and comparing, not for confidentiality of recoverable data.

Does using bcrypt mean I've handled authorization for my application?

No. Bcrypt only supports one part of authentication, specifically, verifying a knowledge-factor credential (a password) during the authentication step. It says nothing about what an authenticated principal is permitted to do, which is authorization and is handled separately by your access control model (for example RBAC or ABAC). Bcrypt also does not by itself provide multi-factor authentication or identity proofing.

How should the bcrypt cost factor (work factor) be chosen?

The cost factor determines the number of hashing rounds and thus the computational effort per hash. It is typically chosen so that hashing takes an acceptable amount of time on your target hardware while remaining costly for attackers, and it is commonly revisited over time as hardware improves. The appropriate value depends on your deployment's performance constraints and threat model, so treat any specific number as configuration-dependent rather than universal.

How do I handle rehashing when I increase the cost factor?

Because bcrypt stores its cost factor within the resulting hash string, a common pattern is to check the stored cost at successful login and, if it is below your current target, re-hash the just-verified plaintext password with the new cost and update the stored value. This lets you migrate credentials gradually as users authenticate, depending on your application's session and login flow.

Do I need to manage salts separately when using bcrypt?

In most bcrypt implementations the salt is generated automatically and embedded within the output hash string alongside the cost factor and the hash itself, so it is stored together with the credential rather than in a separate column. You typically do not manage salts manually, though you should confirm this behavior in your specific library rather than assuming it.

Are there input length considerations when using bcrypt?

Many bcrypt implementations truncate or otherwise limit password input beyond a certain byte length, which can affect very long passwords or passphrases. Behavior here varies by implementation, so consult your library's documentation; some deployments pre-hash the input before passing it to bcrypt to work around length limits, though this introduces its own considerations that should be evaluated against your threat model.

Common misconceptions

bcrypt encrypts passwords, so they can be decrypted if needed.

bcrypt is a one-way password hashing function, not an encryption algorithm. There is no decryption operation; verification works by hashing the supplied password with the stored salt and cost and comparing the result. Hashing and encryption are distinct concepts.

You must generate and store a separate salt when using bcrypt.

bcrypt generates a per-hash salt automatically and embeds it in the output string, so in most implementations a separate salt column is unnecessary.

A given bcrypt cost factor is secure permanently.

The appropriate cost depends on current hardware and threat context. Because the work factor is adaptive by design, deployments typically need to reassess and raise it over time to keep cracking expensive.

Best practices

Select a cost factor appropriate to your hardware and latency budget, and revisit it periodically, increasing it as computational capacity grows.

Rely on bcrypt's built-in salt generation rather than implementing your own salting scheme, and store the full self-contained hash string so the algorithm, cost, and salt are preserved.

Use bcrypt only for password verifier storage; do not repurpose it as an encryption mechanism or for hashing large data where a fast hash is expected.

Be aware of input length handling in your bcrypt implementation and validate behavior for long passwords, since implementations may differ depending on configuration.

When raising the cost factor, plan a migration strategy that re-hashes credentials on next successful authentication so existing stored hashes are upgraded transparently.

Combine bcrypt password storage with additional controls such as MFA and rate limiting, since strong hashing mitigates but does not eliminate the impact of credential exposure.