Bcrypt vs SHA-256: Why You Don't Hash Passwords with SHA

"Just hash the password with SHA-256" is one of the most common — and most dangerous — pieces of advice in software. SHA-256 is an excellent hash function, but it's the wrong tool for storing passwords. Here's why, and what to use instead.

Hashing vs encryption (a quick reminder)

A hash is a one-way function: you can compute it, but you can't reverse it to recover the input. Storing a password's hash means that even if your database leaks, attackers don't immediately have the plain passwords. That's the right idea — the problem is which hash, and how it's used.

The problem with SHA-256 for passwords

SHA-256 is designed to be fast. That's a feature for verifying file integrity, where you might hash gigabytes. But for passwords, speed helps the attacker. Modern hardware can compute billions of SHA-256 hashes per second. If your password database leaks, an attacker can guess billions of candidate passwords per second against it, cracking weak and medium-strength passwords almost instantly.

Worse, a plain unsalted hash means identical passwords produce identical hashes. Attackers precompute huge tables of hashes for common passwords ("rainbow tables") and simply look yours up.

What a salt does

A salt is a random value added to each password before hashing. Because every user gets a different salt, identical passwords produce different hashes, which defeats rainbow tables and forces the attacker to crack each hash individually. Salting is essential — but on its own it doesn't fix the speed problem.

How bcrypt fixes it

Bcrypt is a password-hashing function built for this job. It does two things SHA-256 doesn't:

• It salts automatically. A random salt is generated and stored inside the hash output, so you don't manage it separately.
• It's deliberately slow, and tunable. A cost factor controls how many rounds of work each hash takes. Each increment doubles the cost. A cost of 12 might take a quarter of a second — trivial for one login, but devastating for an attacker trying billions of guesses.

A bcrypt hash looks like $2b$12$N9qo8uLO...: the algorithm, the cost, then the salt and hash together. Because the salt and cost live in the string, the verifier has everything it needs to check a password later.

What about Argon2 and scrypt?

Bcrypt is a solid default, but Argon2 (the winner of the Password Hashing Competition) and scrypt are also excellent. They add memory-hardness — they require lots of RAM, which blunts attackers using GPUs and custom hardware. If your platform supports Argon2id, it's a great choice; bcrypt remains perfectly respectable and is widely available.

Modern best practice

• Use bcrypt, scrypt or Argon2 — never a bare SHA or MD5 — to store passwords.
• Tune the cost so a single hash takes a noticeable fraction of a second on your hardware.
• Screen new passwords against known-breached lists rather than imposing arbitrary complexity rules.
• Add multi-factor authentication, which protects accounts even if a password is cracked.

Try it

Generate and verify bcrypt hashes — and watch how the cost factor changes the time — with our bcrypt generator & checker. Compare that with the instant output of the hash generator (MD5/SHA) to feel the speed difference for yourself. To define rules for your organisation, use the password policy generator.