Password hashing with bcrypt in FastAPI - Deep Dive

Overview - Password hashing with bcrypt

What is it?

Password hashing with bcrypt is a way to securely store user passwords by turning them into a scrambled code that is hard to reverse. Instead of saving the actual password, the system saves this scrambled version. When a user logs in, their password is scrambled the same way and compared to the stored code. This keeps passwords safe even if someone steals the stored data.

Why it matters

Without password hashing, if a hacker steals the password database, they get all user passwords in plain text, risking user accounts everywhere. Bcrypt makes it very hard for attackers to guess the original password, protecting users and systems from breaches and identity theft. It builds trust and keeps data safe in a world full of cyber threats.

Where it fits

Before learning bcrypt hashing, you should understand basic Python programming and how FastAPI handles user input and responses. After mastering bcrypt, you can learn about full user authentication systems, token-based security, and advanced encryption methods.

Mental Model

Core Idea

Bcrypt transforms a password into a unique, slow-to-compute code that safely hides the original password and resists guessing attacks.

Think of it like...

Imagine locking your house with a special lock that takes time to open and changes its pattern every time you lock it. Even if someone finds the lock, it’s very hard and slow to figure out how to open it without the key.

Password Input
    ↓
[ Bcrypt Hash Function ]
    ↓
Hashed Password Stored

Login Attempt
    ↓
[ Bcrypt Hash Function ]
    ↓
Compare Hashed Passwords
    ↓
Access Granted or Denied

Build-Up - 6 Steps

1

Foundation

Understanding Plain Password Risks

Concept: Learn why storing plain passwords is dangerous.

When passwords are saved as plain text, anyone who accesses the database can see them exactly as users typed. This means if the database is leaked or hacked, all user accounts are immediately at risk. Plain passwords offer no protection.

Result

You realize that plain password storage is a major security risk.

Understanding the risk of plain passwords motivates the need for secure password handling.

2

Foundation

What Is Password Hashing?

Concept: Introduce the idea of hashing as a one-way scramble of data.

Hashing takes a password and runs it through a function that turns it into a fixed-length string of characters. This process cannot be reversed to get the original password. Hashing ensures passwords are not stored in readable form.

Result

You know that hashing protects passwords by hiding their original form.

Knowing hashing is one-way helps you understand why it’s safer than encryption for passwords.

3

Intermediate

Why Bcrypt Is Special for Passwords

🤔Before reading on: Do you think all hash functions are equally good for passwords? Commit to your answer.

Concept: Bcrypt adds extra security by being slow and using a salt to protect against guessing and rainbow table attacks.

Bcrypt is designed to be slow to compute, which means attackers cannot quickly try many passwords. It also adds a random salt (extra random data) to each password before hashing, so even identical passwords have different hashes. This stops attackers from using precomputed tables to crack passwords.

Result

You understand bcrypt’s slow and salted hashing makes password cracking much harder.

Knowing bcrypt’s design prevents fast guessing and identical hash reuse is key to strong password security.

4

Intermediate

Using Bcrypt in FastAPI

🤔Before reading on: Do you think bcrypt hashing is done automatically by FastAPI or requires explicit code? Commit to your answer.

Concept: Learn how to use the bcrypt library in FastAPI to hash and verify passwords.

In FastAPI, you install the bcrypt library and use it to hash passwords before saving. When users log in, you use bcrypt to check if the entered password matches the stored hash. This requires explicit code to hash and verify passwords using bcrypt functions.

Result

You can write FastAPI code that safely hashes and checks passwords with bcrypt.

Understanding that bcrypt requires explicit use in code helps avoid security mistakes.

5

Advanced

Choosing Bcrypt Work Factor

🤔Before reading on: Do you think higher work factor always means better security without downsides? Commit to your answer.

Concept: The work factor controls how slow bcrypt hashing is, balancing security and performance.

Bcrypt’s work factor (or rounds) determines how many times the hashing process repeats, making it slower and harder to crack. Higher work factor means better security but slower login times. You must choose a work factor that protects users without making your app too slow.

Result

You know how to balance security and speed by adjusting bcrypt’s work factor.

Knowing the tradeoff between security and performance prevents poor user experience or weak protection.

6

Expert

Bcrypt Internals and Attack Resistance

🤔Before reading on: Do you think bcrypt is vulnerable to GPU cracking like simple hashes? Commit to your answer.

Concept: Explore how bcrypt’s design resists modern cracking methods like GPU attacks.

Bcrypt uses a memory-hard algorithm that requires significant memory and CPU time, making it inefficient for GPUs and ASICs to crack. This design slows down attackers using specialized hardware. It also includes a salt and adaptive work factor to stay strong as hardware improves.

Result

You understand why bcrypt remains secure against advanced cracking techniques.

Understanding bcrypt’s memory-hard design explains why it’s preferred over simpler hashes for passwords.

Under the Hood

Bcrypt works by taking the password and a random salt, then running them through a key setup phase of the Blowfish cipher multiple times based on the work factor. This process produces a hash that includes the salt and work factor, allowing verification later. The repeated processing makes hashing slow and memory-intensive, which defends against brute-force attacks.

Why designed this way?

Bcrypt was created to improve on fast hash functions like MD5 or SHA that are vulnerable to fast cracking. By making hashing slow and memory-heavy, bcrypt forces attackers to spend more time and resources per guess. The salt prevents attackers from using precomputed tables. This design balances security and usability.

┌───────────────┐
│ User Password │
└──────┬────────┘
       │
       ▼
┌───────────────┐      ┌───────────────┐
│   Generate    │      │   Work Factor │
│    Random     │      │  (Cost Value) │
│     Salt      │      └──────┬────────┘
└──────┬────────┘             │
       │                      ▼
       │             ┌────────────────────┐
       │             │  Blowfish Key Setup │
       │             │  with Password +    │
       │             │  Salt repeated N    │
       │             │  times (work factor)│
       │             └─────────┬──────────┘
       │                       │
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│  Store Hash   │◄──────┤  Hashed Output│
│ (includes salt│       │  (hash string)│
│  and work)    │       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does bcrypt hashing produce the same hash for the same password every time? Commit to yes or no.

Common Belief: Bcrypt always produces the same hash for the same password.

Reality: Bcrypt produces different hashes each time because it uses a random salt.

Why it matters: Assuming hashes are the same can lead to insecure password storage or failed login checks.

Quick: Is bcrypt hashing fast enough to use without any performance concerns? Commit to yes or no.

Common Belief: Bcrypt hashing is fast and does not affect application speed.

Reality: Bcrypt is intentionally slow to increase security, which can impact performance if not managed.

Why it matters: Ignoring bcrypt’s slowness can cause slow logins or server overload under heavy use.

Quick: Can you reverse a bcrypt hash to get the original password? Commit to yes or no.

Common Belief: You can reverse bcrypt hashes to find the original password if you have enough computing power.

Reality: Bcrypt hashes cannot be reversed; only guessing and checking can find the password.

Why it matters: Believing hashes are reversible may cause false confidence in password security.

Quick: Does increasing bcrypt’s work factor always improve security without drawbacks? Commit to yes or no.

Common Belief: Higher work factor always means better security with no downsides.

Reality: Higher work factor improves security but also slows down authentication and increases resource use.

Why it matters: Ignoring performance tradeoffs can degrade user experience or system stability.

Expert Zone

1

Bcrypt’s salt is embedded in the stored hash string, allowing verification without separate salt storage.

2

The work factor can be adjusted over time to keep up with hardware improvements without changing stored hashes.

3

Bcrypt is resistant to rainbow table attacks due to unique salts but not immune to weak password guessing.

When NOT to use

Avoid bcrypt when you need extremely fast hashing for non-password data or when using hardware with limited CPU resources. Alternatives like Argon2 offer better memory-hardness and resistance to side-channel attacks. For legacy systems, PBKDF2 might be used but is less secure.

Production Patterns

In real systems, bcrypt hashes are stored in user databases with the salt and work factor included. Systems often include password strength checks before hashing. Work factor is chosen based on server capacity and updated periodically. Verification is done on login by hashing the input password with the stored salt and comparing hashes.

Connections

Cryptographic Salt

Bcrypt builds on the concept of salt by embedding it in the hash to prevent precomputed attacks.

Understanding salt helps grasp why bcrypt hashes differ even for identical passwords.

Rate Limiting

Bcrypt’s slowness complements rate limiting by making brute-force attacks computationally expensive and slow.

Knowing both helps design layered defenses against password guessing.

Human Memory and Password Strength

Bcrypt protects weak human-chosen passwords but cannot fix poor password choices.

Understanding human factors highlights why password policies and hashing must work together.

Common Pitfalls

#1 Storing passwords without hashing.

Wrong approach:

user_password = input_password # Stored directly in database

Correct approach:

hashed_password = bcrypt.hashpw(input_password.encode(), bcrypt.gensalt()) # Store hashed password

Root cause:

Misunderstanding that plain text storage is acceptable or secure.

#2 Using a fixed salt instead of a random salt.

Wrong approach:

salt = b'static_salt'
hashed = bcrypt.hashpw(password.encode(), salt)

Correct approach:

hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

Root cause:

Not realizing that a unique random salt per password is essential for security.

#3 Not verifying passwords correctly using bcrypt.

Wrong approach:

if bcrypt.hashpw(input_password.encode(), stored_hash) == stored_hash:
allow_access()

Correct approach:

if bcrypt.checkpw(input_password.encode(), stored_hash):
allow_access()

Root cause:

Confusing how to compare hashed passwords leading to failed or insecure verification.

Key Takeaways

Always hash passwords with bcrypt before storing to protect user data from leaks.

Bcrypt uses a random salt and a work factor to make hashes unique and slow to compute, increasing security.

Choosing the right work factor balances security and application performance.

Never store or compare passwords in plain text; always use bcrypt’s hash and check functions.

Understanding bcrypt’s internal design helps you trust its resistance to modern cracking methods.