How to Use bcrypt for Password Hashing

Problem

You need to store user passwords securely so that even if the database is compromised, the passwords cannot be recovered.

Prerequisites

• Understanding of hashing vs encryption
• Knowledge of salt and cost factor

Steps

1. 1. Choose a cost factor

   The bcrypt cost factor determines how many iterations the hashing runs. A cost of 10 takes about 100ms; each increment doubles the time. Choose the highest cost your server can afford during login (typically 10-12).

   Input

   cost: 12

   Output

   ~400ms per hash

2. 2. Hash the password with a generated salt

   bcrypt automatically generates a random salt and embeds it in the hash. You do not need to manage the salt separately. The output is a single string containing the algorithm, cost, salt, and hash.

   Input

   password: 'correct horse'

   Output

   $2b$12$...salt+hash...

3. 3. Verify on login

   To check a password, pass the candidate password and the stored bcrypt hash to the verify function. It extracts the salt and cost from the hash and re-computes, then compares the result. Never compare hashes manually with ==.

   Input

   candidate + stored hash

   Output

   true / false

Expected result

A bcrypt hash string that can verify passwords without storing the plaintext, with adjustable work factor.

Common errors

Cost factor too low

A cost below 10 is too fast for modern hardware. Increase to at least 10-12 to resist GPU brute force.

Using a fixed salt

Let bcrypt generate a random salt per password. A fixed salt enables precomputation attacks like rainbow tables.

Troubleshooting

• If hashing is too slow, lower the cost by 1. If too fast, raise it.
• If verify always returns false, check that you are passing the full bcrypt hash string, not just the hash portion.

Security limits

• bcrypt has a 72-byte password limit; longer passwords are truncated. Pre-hash with SHA-256 if you need to support longer passwords.
• All hashing is done locally; no password leaves your browser.