Why use bcrypt and what to expect

bcrypt is a widely used password hashing algorithm designed to be slow and resistant to brute-force attacks. Unlike a simple hash function, bcrypt includes a configurable cost factor that lets you tune time-to-compute as hardware improves, and it automatically generates a salt for each hash so identical passwords produce different hashes. When setting up bcrypt in an application, the main tasks are installing a reliable implementation, choosing an appropriate cost (also called rounds), integrating hashing and verification where users register and log in, and planning for future rehashing and migration. The following sections walk through practical steps for several common environments and cover security and deployment considerations you should not skip.

Prerequisites

Before you begin, make sure your development environment is ready: you need access to your project source, your package manager or build system (npm, pip, Maven/Gradle), and a way to test hashing performance on representative hardware. You should also have secure storage for user records (a database), and a plan for secret handling if you use environment-specific configuration. Testing in a staging environment that mimics production will help pick a sensible cost factor without slowing real users.

Key bcrypt concepts to know

There are a few terms worth understanding up front. A “salt” is a per-hash random value that the library uses automatically; you don’t need to store it separately because bcrypt encodes the salt into the resulting hash string. The “cost” or “rounds” parameter controls how many internal iterations are applied , higher cost increases compute time exponentially. You should measure how long a single hash takes at different costs on your production-class hardware and pick a number that balances security and user experience (commonly 10–14). Finally, bcrypt is intentionally slow and not intended for general-purpose encryption or symmetric keyed operations; treat it strictly for hashing passwords and other high-value secrets.

Step-by-step: Node.js (bcrypt or bcryptjs)

1) Install the package

For Node.js, you can use the native bindings package or a pure JS fallback. Install one of these:

npm install bcrypt

# or, if you want a pure JS implementation

npm install bcryptjs

bcrypt uses native bindings and is typically faster, but may require build tools on some platforms. bcryptjs is easier to install but somewhat slower.

2) Basic hashing and verifying

Use a cost (salt rounds) constant and keep it configurable via environment variables. Always use async methods to avoid blocking the event loop. Example with bcrypt:

const bcrypt = require('bcrypt');

const SALT_ROUNDS = parseInt(process.env.BCRYPT_ROUNDS || '12', 10);
// Creating a hash

async function hashPassword(plain) {

  return await bcrypt.hash(plain, SALT_ROUNDS);

}
// Verifying a password

async function verifyPassword(plain, hash) {

  return await bcrypt.compare(plain, hash);

}

3) Integration tips

Hash on registration and any password change, store only the hash string in the database, and use compare during login. Don’t attempt to re-salt or alter the stored hash manually , let the library handle it. When you update the cost factor, check at login whether the stored hash uses an older cost and, if so, rehash the password after successful verification to keep stored hashes up to date.

Step-by-step: Python (bcrypt package)

1) Install

The recommended package is bcrypt which wraps the C library. Install it with pip inside your virtual environment:

pip install bcrypt

2) Hashing and checking

In Python, the API is straightforward. Work with bytes, and keep the cost in a variable. Example:

import bcrypt

BCRYPT_ROUNDS = int(os.getenv('BCRYPT_ROUNDS', '12'))
def hash_password(plain_text):

    password = plain_text.encode('utf-8')

    salt = bcrypt.gensalt(rounds=BCRYPT_ROUNDS)

    return bcrypt.hashpw(password, salt)  # returns bytes
def check_password(plain_text, hashed):

    return bcrypt.checkpw(plain_text.encode('utf-8'), hashed)

Step-by-step: Java (Spring Security / BCryptPasswordEncoder)

Java projects often use Spring Security’s BCryptPasswordEncoder. Configure the encoder as a bean and set the strength (log rounds). Example:

import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
int strength = Integer.parseInt(System.getenv().getOrDefault("BCRYPT_ROUNDS", "12"));

BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(strength);
// Hashing

String hashed = encoder.encode(rawPassword);
// Verifying

boolean matches = encoder.matches(rawPassword, hashed);

When integrating into authentication flows, use the encoder for both registration and authentication. Spring Security’s configuration can automatically call the encoder when Spring-managed authentication occurs.

Choosing the right cost factor

Choosing the cost factor is a balancing act. Measure hash time on your slowest production server and aim for roughly 100–500ms per operation if your traffic and ux allow it. Too low and brute-force attacks become feasible; too high and logins/timeouts will suffer. Test with realistic concurrency to ensure your servers can handle spikes. Make the cost adjustable through an environment variable so you can raise it later without changing code.

Security and operational considerations

Store only the bcrypt hash string in your database; it contains the algorithm id, rounds, salt, and hash. Protect database backups and restrict access to user tables. Plan rehashing: when a user logs in, verify the password and check the encoded rounds value; if your configured rounds is higher than the stored one, rehash the password and update the record. Avoid rolling your own salting or key derivation; use well-maintained libraries and keep them updated. Additionally, use tls for all authentication endpoints, apply rate limiting and account lockouts for repeated failed attempts, and monitor for credential stuffing or unusual login patterns.

Checklist before going to production

Run through this short checklist to reduce common mistakes and omissions:

Measure hashing latency on production-class hardware and set rounds accordingly.

Use async/non-blocking APIs where available to prevent thread/event loop blocking.

Store only the hash string, and protect backups and DB access.

Implement rehashing on login when rounds change.

Use TLS, rate limiting, and logging for authentication endpoints.

Keep bcrypt libraries up to date and subscribe to security release notes.

Common pitfalls and how to avoid them

Avoid using very low cost factors to preserve user experience at the expense of security. Don’t try to optimize by storing salts separately or using predictable random values. Avoid synchronous hash calls in environments where they block (Node.js main thread, single-threaded servers). If migrating from a weaker hash (MD5, SHA1, unsalted), authenticate users with the old hash and rehash with bcrypt after successful login, or force a password reset if rehashing isn’t practical.

Concise summary

Install a well-maintained bcrypt implementation for your platform, choose and test an appropriate cost factor on production-like hardware, hash passwords on registration and verify on login using library APIs, store only the resulting hash, and plan for rehashing when you change cost. Protect your storage and endpoints with TLS, rate limiting, and access controls. With these steps in place, bcrypt will provide a strong, future-resilient defense for user credentials.

FAQs

How many rounds should I use for bcrypt?

There’s no single correct number. Measure hash time on your target servers and choose a cost that gives acceptable latency (commonly 10–14). Aim for a perceptible but short delay (100–500ms) per hash where possible, then adjust based on traffic and concurrency.

Do I need to store the salt separately?

No. bcrypt encodes the salt into the produced hash string, so storing the hash is sufficient. The salt is unique per hash and will be used by the library during verification.

Should I use bcryptjs or bcrypt in Node.js?

bcrypt (native bindings) is generally faster but may require build tools on some environments. bcryptjs is easier to install because it’s pure JavaScript but slightly slower. Use what fits your deployment environment; performance testing will reveal whether the pure-JS implementation is acceptable.

How do I migrate users from an old hashing scheme?

The safest approach is to verify passwords against the old scheme at login. On successful authentication, rehash the password with bcrypt and update the stored value. If you cannot rehash at login, consider forcing a password reset for affected users.

Is bcrypt still secure in 2025?

Yes, bcrypt remains a widely recommended password hashing algorithm. It is designed to be slow and tunable. While newer functions like Argon2 offer additional defenses (memory hardness), bcrypt is still secure when configured with an appropriate cost factor and combined with standard defenses like TLS, rate limiting, and secure storage.