Password Hashing with Bcrypt and Salts

The Cardinal Sin: Storing Plaintext Passwords

It might seem obvious, but the number one rule is to never, ever store a user's password in a recoverable format. Storing passwords as plain text in your database is a catastrophic liability. If an attacker breaches your database, they instantly have the credentials for every single one of your users.

A common first thought might be, "Okay, I'll just encrypt the passwords." However, this is also incorrect.

As the article states, encryption is reversible. If an attacker steals your database and your encryption key, they can decrypt all the passwords. The goal is not to hide the password, but to make it impossible to recover, while still being able to verify it. This is where hashing comes in.

Hashing: The One-Way Street

Hashing is a process that takes an input (like a password) and produces a fixed-size string of characters, called a hash. This process is designed to be a one-way function. You can easily compute the hash from the password, but you cannot compute the password from the hash.

So, the process is:

1. Sign-up: Hash the user's password and store the hash in the database.
2. Login: Hash the password the user enters and compare it to the stored hash. If they match, the password is correct.

However, using a simple, fast hash function like SHA-256 is still dangerously insecure for passwords. Why? Because an attacker who steals your database can still crack the passwords.

The Problem with Fast Hashes and the Solution: Salting

Fast hash functions are vulnerable to two main types of attacks:

1. Dictionary Attack: The attacker takes a huge list of common passwords, hashes them all, and sees if any match the hashes in your stolen database.
2. Rainbow Table Attack: This is a pre-computed dictionary attack. Attackers have massive tables that map pre-computed hashes back to the passwords that created them.

The video below demonstrates just how easy it is to "reverse" a hash from an old algorithm like MD5 using these techniques.

The core problem is that for a given hashing algorithm, the same password always produces the same hash. This allows for these pre-computation attacks. The solution is to make every hash unique, even for the same password. We do this with a salt.

A salt is a unique, random string of data that is generated for each user and combined with their password before hashing.

HashedPassword = HashFunction(Password + Salt)

This simple addition has two profound effects:

1. It renders rainbow tables useless because the hashes are no longer pre-computable. An attacker would need a separate rainbow table for every possible salt, which is computationally impossible.
2. It ensures that if two users have the same password, their stored hashes will be different because they will have different salts.

Now, let's see how salting works in practice.

The salt is not a secret; it's stored right alongside the user's hashed password in the database. When the user logs in, you retrieve both their salt and their stored hash. You then combine the password they entered with the retrieved salt and hash it. If the result matches the stored hash, the login is successful.

The Final Piece: Deliberately Slow Hashing with bcrypt

Salting protects against mass, pre-computed attacks. But what if an attacker gets your database and decides to focus all their computing power on cracking a single user's password? They can still perform a dictionary attack on that one hash. With modern GPUs, they can try billions of passwords per second.

This is where the most important innovation in modern password hashing comes in: deliberate slowness.

Algorithms like bcrypt, scrypt, and Argon2 are designed to be computationally expensive. They introduce an adjustable work factor (also called a cost factor or salt rounds) that forces the CPU to perform thousands of iterations to compute a single hash.

This slowness creates a massive asymmetry:

• For a legitimate user: Waiting 200 milliseconds for a single hash during login is unnoticeable.
• For an attacker: The same 200ms delay reduces their billion-guesses-per-second attack to just 5 guesses per second, making a brute-force attack completely impractical.

The work factor is adaptive. As computers get faster over the next few years, you can simply increase the work factor to maintain the same level of security, without changing the algorithm itself.

A Deeper Look at bcrypt

Since you're interested in the deep technical details, let's explore how bcrypt achieves this.

As you read, the key takeaway is that bcrypt's strength comes from exploiting the intentionally slow key setup phase of the Blowfish cipher. The work factor exponentially increases the number of times this slow process is run.

The final bcrypt hash string elegantly encodes all the necessary information to verify a password later:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

• $2b$: The bcrypt algorithm version.
• 12: The work factor (cost). In this case, 2¹² iterations.
• R9h/cIPz0gi.URNNX3kh2O: The 128-bit salt, Base64 encoded.
• PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW: The actual hashed output, Base64 encoded.

When you call a verification function like bcrypt.compare(password, hash), the library parses this string, extracts the salt and work factor, re-hashes the provided password with the exact same parameters, and performs a secure comparison.

Practical Implementation in Python

Let's see how this looks in Python, which is directly relevant to your work with Django. Django itself uses a pluggable password hashing system and recommends using bcrypt or Argon2.

The following code snippet is a best-practice implementation for hashing and verifying passwords with the bcrypt library in Python. It also includes a crucial detail for handling a known limitation of bcrypt.

The key functions from the bcrypt library are:

• bcrypt.gensalt(rounds=12): Generates a random salt with a specified work factor.
• bcrypt.hashpw(password_bytes, salt): Hashes the password using the provided salt.
• bcrypt.checkpw(password_bytes, hash_bytes): The verification function. It securely compares a plaintext password against a stored hash and returns True or False. This function handles the parsing of the hash string and performs a constant-time comparison to prevent timing attacks.

Common Mistakes to Avoid

Even when using a strong library, it's possible to make implementation mistakes that undermine security.

1. Using an insufficient work factor: A work factor of 4 is useless. Follow OWASP recommendations (currently 10 minimum, 12+ recommended). Benchmark on your production hardware and aim for a hash time between 200-500ms.
2. Not using a constant-time comparison: A simple string comparison like hash1 == hash2 can leak information through timing differences. Always use the library's built-in verification function (bcrypt.checkpw in Python).
3. Rolling your own crypto: Never try to invent your own hashing scheme. Use battle-tested libraries and algorithms.
4. Using a static salt: The salt must be unique for every user. Good libraries handle this for you.

Conclusion

In this lesson, we've gone from the root of why we can't store plaintext passwords to the modern, robust solution provided by slow, adaptive hashing algorithms like bcrypt.

Key Takeaways:

• Hash, Don't Encrypt: Passwords must be processed with a one-way hash function.
• Salt Everything: A unique, random salt for every password defeats pre-computation attacks like rainbow tables.
• Slow is Strong: Use a deliberately slow algorithm like bcrypt with a configurable work factor. This makes brute-force attacks against a stolen database computationally infeasible.
• Be Adaptive: The work factor allows you to increase hashing difficulty over time as computing power increases, keeping your security robust.
• Use Libraries Correctly: Rely on trusted libraries like bcrypt and use their built-in functions for hashing (hashpw) and verification (checkpw) to avoid common pitfalls.

Preview of the Next Lesson

Now that we understand how to securely store a representation of a user's password, our next step is to explore how we use this to manage a user's logged-in state. In the next lesson, we will describe the flow of session-based authentication, including cookie management and server-side session storage. We'll see how a successful password verification kicks off a stateful relationship between the client and server.