Password Hashing with bcrypt: Why Salted Hashes Matter

Storing passwords correctly is one of the most critical responsibilities of a developer handling user accounts. Despite decades of guidance, password hashing mistakes continue to cause massive breaches. This guide explains why you need a specialized password hashing algorithm like bcrypt and what makes it different from general-purpose hash functions.

Never Store Plaintext Passwords

If your database is compromised, plaintext passwords expose every user’s credentials immediately — including their passwords on other sites, since most people reuse passwords. Always hash passwords before storing them. Hashing is a one-way function: you can verify a password by hashing the input and comparing, but you can’t reverse a hash to get the original password.

Why MD5 and SHA Are Wrong for Passwords

MD5 and SHA-256 are designed to be fast — millions of hashes per second on modern hardware. That’s exactly what you don’t want for password hashing. An attacker with a stolen hash database can run brute force or dictionary attacks at enormous speed. Modern GPUs can compute billions of MD5 hashes per second.

What Makes bcrypt Different

bcrypt was designed specifically for password hashing. It incorporates an adjustable cost factor (work factor) that controls how computationally expensive the hash is to compute. Higher cost means slower hashing — but that’s the point. The cost factor can be increased over time as hardware gets faster, keeping bcrypt resistant to brute force attacks.

Why Salts Matter

A salt is a random value generated for each password and incorporated into the hash. bcrypt generates a unique 128-bit salt automatically. Salts prevent rainbow table attacks (precomputed hash lookups) and ensure that two users with the same password have different hashes in the database. An attacker with the hash database must crack each hash individually.

Choosing a Cost Factor

The bcrypt cost factor is a power of 2 — a cost of 12 means 2^12 = 4,096 iterations. The recommended minimum in 2024 is cost 12. Target a hash time of 100-300ms on your servers — slow enough to deter brute force, fast enough for good UX. Test your chosen cost factor on your specific hardware.

Alternatives: Argon2 and scrypt

Argon2 (winner of the Password Hashing Competition) and scrypt are also excellent choices. Argon2id is the modern recommendation from OWASP, as it is memory-hard in addition to computationally expensive, making GPU-based attacks even harder. If you’re starting a new project, consider Argon2id over bcrypt.

Generate secure random values. Use the Hash Generator on devutilitypro.com to generate SHA-256, MD5, and other hashes for testing and comparison purposes.