As a website owner you are responsible for protecting users’ passwords. Bcrypt is a well-established password hashing function that makes it expensive for attackers to crack stored credentials, while being straightforward to use in most web stacks. This guide explains what bcrypt does, how to pick the right settings, practical implementation snippets, and sensible policies for handling passwords and migrations so you can raise security without hurting user experience.
Why bcrypt matters for website security
Storing plain or simply hashed passwords is risky because attackers who obtain your database can run fast offline guesses. Bcrypt intentionally slows down hashing and includes per-password salts, so two identical passwords produce different hashes and automated cracking takes far more time and resources. For website owners the main benefits are minimized damage from breaches and improved compliance with common security standards. Bcrypt is not encryption , it is a one-way function designed specifically for password storage , so you won’t be able to recover a password, only verify it.
Key properties in plain terms
Bcrypt combines a salt and a configurable cost factor to produce a single string that contains all the information needed for verification. The salt prevents precomputed attacks and rainbow tables. The cost , sometimes called rounds or work factor , controls how expensive hashing is. Increasing cost makes both legitimate login checks and attack attempts slower; the goal is to make legitimate checks fast enough for users but slow enough to impede attackers attempting millions of guesses.
How bcrypt works and what to watch for
At a high level bcrypt takes a password and a salt, runs a number of internal iterations controlled by the cost factor, and returns a hash that encodes the salt and cost. Most bcrypt libraries output a single string you can store directly in your user table. Important practical details to keep in mind: many bcrypt implementations effectively limit the input to 72 bytes, so very long or UTF-8-heavy passwords may be truncated unless you pre-hash them. Also, bcrypt uses a fixed algorithm; when hardware improves you should increase the cost factor and re-hash active passwords over time.
Limitations and how to handle them
If you expect users to use extremely long passphrases or you want to avoid the 72-byte limitation, a common approach is to pre-hash the password with SHA-256 and feed that fixed-length output to bcrypt. That keeps bcrypt’s protections while preserving full password entropy. Another option is to consider newer algorithms like Argon2 if you want memory-hard hashing, although bcrypt remains widely supported and compatible with many libraries and frameworks.
Choosing the right cost factor
There is no single correct number for cost. The practical way to pick one is to benchmark hashing on your own server hardware and choose a cost that produces an acceptable delay for login operations , commonly something in the 100–500 millisecond range depending on traffic patterns. If your application does a lot of logins per second, a lower cost can keep performance manageable; if logins are rare, you can pick a higher cost for stronger protection. Record your benchmarking and revisit the cost annually or when you upgrade server hardware.
Implementation examples
Below are concise example implementations for Node.js, php, and Python. Each example shows how to hash a password on registration and how to verify it at login. These snippets assume you already use secure transport (https) and have sanitized inputs where necessary.
Node.js (bcrypt)
// Install: npm install bcrypt
const bcrypt = require('bcrypt');
const SALT_ROUNDS = 12;
// Hashing
async function hashPassword(plain) {
return await bcrypt.hash(plain, SALT_ROUNDS);
}
// Verification
async function checkPassword(plain, storedHash) {
return await bcrypt.compare(plain, storedHash);
}PHP (password_hash / password_verify)
// Built-in functions available in modern PHP versions
$password = 'user-provided-password';
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);
// Verify
if (password_verify($password, $hash)) {
// success
}Python (bcrypt library)
# Install: pip install bcrypt
import bcrypt
def hash_password(password: str) -> bytes:
pw = password.encode('utf-8')
salt = bcrypt.gensalt(rounds=12)
return bcrypt.hashpw(pw, salt)
def check_password(password: str, stored: bytes) -> bool:
return bcrypt.checkpw(password.encode('utf-8'), stored)Best practices for website owners
Protecting passwords involves more than picking bcrypt. Make sure your entire authentication flow defends against common attacks and reduces risk if a breach happens. Use HTTPS for all authentication traffic so passwords never travel in clear text. Store only the bcrypt hash in your database; never store raw passwords, and don’t try to encrypt them with reversible keys. Combine bcrypt with other protections such as rate limiting and login throttling so an attacker can’t try many guesses quickly. Consider a server-side pepper , a secret stored outside the database that you append to passwords before hashing , but keep it secret and manageable for key rotation. When users create or change passwords, apply reasonable password strength checks and guide them toward longer passphrases rather than complex rules that push users to reuse passwords across sites.
migrating old password stores
If you have legacy hashes (MD5, SHA-1, unsalted SHA-256), adopt an in-place migration path: keep the old hashes to verify on login, and when a user successfully logs in, re-hash their password with bcrypt and update the stored value. Optionally add a column indicating the algorithm used so you can handle verification correctly. For large user bases you can also roll out forced resets for inactive accounts where re-hash-on-login would take too long to complete the transition.
Operational tips and monitoring
Monitor the impact of bcrypt on your servers. Because bcrypt intentionally adds CPU cost, high concurrent authentication volume can increase CPU usage and latency during peak periods. If you observe resource pressure, either scale your authentication servers or reduce the cost slightly while planning to increase it later. Log authentication failures for security monitoring, and alert when unusual spikes in failed attempts occur. Periodically test hashing times after deployment to ensure expected performance and to justify potential cost changes.
Summary
Bcrypt is a practical and proven choice for password hashing on websites. It pairs a per-password salt with a configurable cost factor to slow down offline attacks. Choose a cost based on benchmarks on your own hardware, implement correct verification flows, and combine bcrypt with HTTPS, rate limiting, and careful handling of legacy hashes. Where necessary, pre-hash overly long passwords and consider a pepper for an extra layer of defense. With these steps you can significantly reduce the risk to users if your password database is ever exposed.
FAQs
1. Is bcrypt still secure in 2025?
Yes. Bcrypt remains secure for password hashing when used with an appropriate cost factor. Newer algorithms like Argon2 offer memory-hard properties that can provide additional resistance to specialized hardware, but bcrypt is widely supported, well-tested, and appropriate for many applications.
2. What cost factor should I use?
There is no universal value. Run a benchmark on your production hardware and choose a cost that yields an acceptable verification time , typically targeting roughly 100–500 ms per hash depending on traffic and user expectations. Reassess this whenever you upgrade servers.
3. Do I need salt with bcrypt?
No separate salt management is required: bcrypt automatically generates and stores a unique salt inside the resulting hash string. Just store the entire hash and use your library’s verify function.
4. What about the 72-byte limit?
Many bcrypt implementations truncate to 72 bytes. To preserve full password entropy for longer inputs or non-ASCII text, pre-hash the password with SHA-256 and feed the fixed-length digest to bcrypt before hashing.
5. Should I add a pepper?
A pepper , a server-side secret appended to passwords before hashing , can provide extra protection if your database is leaked but the application server secrets remain safe. It complicates key management and rotation, so weigh operational costs and store the pepper separately from the database (for example, in an environment variable or secrets manager).
