Password hashing with Werkzeug in Flask - Deep Dive

Overview - Password hashing with Werkzeug

What is it?

Password hashing with Werkzeug 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 entered password is scrambled the same way and compared to the stored code. This protects user passwords even if the database is stolen.

Why it matters

Without password hashing, if someone steals the database, they get all user passwords in plain text, risking user accounts everywhere. Password hashing stops this by making stolen passwords useless to attackers. It helps keep users safe and builds trust in applications that handle sensitive data.

Where it fits

Before learning password hashing, you should understand basic Python and Flask web app structure. After this, you can learn about user authentication flows, session management, and security best practices like salting and multi-factor authentication.

Mental Model

Core Idea

Password hashing transforms a password into a fixed, scrambled code that cannot be turned back into the original password, ensuring secure storage and verification.

Think of it like...

It's like turning your password into a unique, one-way fingerprint stamp. You can check if a fingerprint matches, but you can't recreate the original finger from the stamp.

Password Input
    ↓
[Hash Function] -- one-way scramble --> [Hashed Password Stored]
    ↑
Password Input on Login
    ↓
[Hash Function]
    ↓
Compare Hashed Passwords
    ↓
Access Granted or Denied

Build-Up - 7 Steps

1

Foundation

Understanding Plain Password Storage Risks

Concept: Why storing passwords as plain text is dangerous.

Imagine a website saves your password exactly as you type it. If hackers get access to this data, they see your real password and can misuse it anywhere you use it. This is why plain password storage is unsafe.

Result

You realize that saving passwords directly exposes users to theft and misuse.

Understanding the risk of plain password storage motivates the need for secure methods like hashing.

2

Foundation

What Is Password Hashing?

Concept: Introducing the idea of one-way password transformation.

Password hashing uses a special function that scrambles a password into a fixed code. This code looks random and cannot be reversed to find the original password. When users log in, their password is hashed again and compared to the stored code.

Result

You grasp that hashing protects passwords by storing only scrambled versions.

Knowing hashing is one-way helps you understand why stolen hashes are safer than plain passwords.

3

Intermediate

Using Werkzeug's generate_password_hash

🤔Before reading on: Do you think generate_password_hash stores the password as plain text or a scrambled code? Commit to your answer.

Concept: How Werkzeug creates a secure hash from a password.

Werkzeug provides generate_password_hash(password) which takes a password string and returns a hashed string using strong algorithms like PBKDF2. This hashed string includes information about the algorithm and salt used.

Result

You get a hashed password string safe to store in your database.

Understanding that generate_password_hash adds salt and algorithm info prevents common security mistakes.

4

Intermediate

Verifying Passwords with check_password_hash

🤔Before reading on: Does check_password_hash compare plain passwords or hashed versions? Commit to your answer.

Concept: How Werkzeug checks if a password matches a stored hash.

check_password_hash(stored_hash, password) hashes the entered password the same way and compares it to stored_hash. It returns True if they match, False otherwise. This lets you verify passwords without knowing the original password.

Result

You can safely check user passwords during login without exposing them.

Knowing verification uses hashing again ensures passwords never travel or compare in plain text.

5

Intermediate

Salting and Why It Matters

🤔Before reading on: Do you think salting means adding a secret key or a random value to passwords? Commit to your answer.

Concept: Salting adds random data to passwords before hashing to prevent attacks.

A salt is a random string added to the password before hashing. Werkzeug automatically adds a unique salt for each password. This stops attackers from using pre-made tables to guess passwords and ensures identical passwords have different hashes.

Result

You understand that salting greatly increases password security.

Recognizing salting prevents common cracking methods helps you appreciate Werkzeug's design.

6

Advanced

Choosing Hashing Algorithms in Werkzeug

🤔Before reading on: Do you think all hashing algorithms are equally secure? Commit to your answer.

Concept: Werkzeug supports multiple algorithms; choosing the right one affects security and speed.

Werkzeug defaults to PBKDF2 with SHA256, a slow and secure algorithm that resists brute force attacks. You can specify others like scrypt or bcrypt. Slower algorithms increase security by making guessing attempts costly.

Result

You learn how to balance security and performance by selecting algorithms.

Understanding algorithm choices helps you tailor security to your app's needs.

7

Expert

Internal Structure of Werkzeug Hash Strings

🤔Before reading on: Do you think the stored hash string contains only the hash or also metadata? Commit to your answer.

Concept: The hashed password string stores algorithm, salt, and hash together for verification.

Werkzeug's hashed password looks like 'method$salt$hash'. This format stores all info needed to verify passwords without external data. When checking, Werkzeug extracts the method and salt to hash the input password correctly.

Result

You see how Werkzeug keeps verification self-contained and secure.

Knowing the hash string format explains why you never need to store salt separately.

Under the Hood

Werkzeug uses cryptographic hash functions that take a password and a salt to produce a fixed-length string. The salt is random and unique per password, preventing identical hashes for same passwords. The hash function is slow and computationally expensive to resist brute force. The output string encodes the algorithm, salt, and hash, allowing verification by reapplying the same process.

Why designed this way?

This design balances security and usability. Storing salt with the hash avoids managing separate data. Using slow algorithms defends against attackers with powerful hardware. The format is standardized for compatibility and ease of use. Alternatives like storing salt separately or using fast hashes were rejected due to security risks.

┌─────────────────────────────┐
│ User Password Input         │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Add Random Salt             │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Apply Slow Hash Function    │
│ (e.g., PBKDF2)             │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Store String:              │
│ method$salt$hash           │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does hashing mean the password can be reversed to plain text? Commit to yes or no.

Common Belief: Hashing passwords means they can be decrypted back to the original password.

Reality: Hashing is one-way and cannot be reversed; you can only verify by hashing again and comparing.

Why it matters: Believing hashes are reversible leads to insecure designs that expose passwords or rely on weak encryption.

Quick: Do you think using the same salt for all passwords is safe? Commit to yes or no.

Common Belief: Using one salt for all passwords is enough to protect them.

Reality: Each password needs a unique salt; using the same salt allows attackers to find patterns and crack multiple passwords.

Why it matters: Reusing salt weakens security and makes mass password cracking easier.

Quick: Is a fast hashing algorithm better for password security? Commit to yes or no.

Common Belief: Faster hashing algorithms improve security by quickly processing passwords.

Reality: Fast algorithms make brute force attacks easier; slow algorithms increase attack cost and improve security.

Why it matters: Choosing fast hashes exposes users to faster cracking and compromises security.

Quick: Does storing the hash string alone mean you must store the salt separately? Commit to yes or no.

Common Belief: You must store the salt separately from the hash to verify passwords.

Reality: Werkzeug stores salt inside the hash string, so no separate storage is needed.

Why it matters: Misunderstanding this leads to complicated and error-prone password storage systems.

Expert Zone

1

Werkzeug's hash strings include versioning, allowing future algorithm upgrades without breaking verification.

2

The default PBKDF2 iteration count can be adjusted to balance security and performance as hardware evolves.

3

Werkzeug supports multiple algorithms transparently, enabling smooth migration between hashing methods.

When NOT to use

Werkzeug password hashing is not suitable for extremely high-performance systems requiring custom hardware acceleration or specialized hashing like Argon2. In such cases, dedicated libraries like 'argon2-cffi' or hardware security modules should be used.

Production Patterns

In production, hashed passwords are stored in user databases with unique salts. Applications use generate_password_hash on signup and check_password_hash on login. Migration scripts update hashes to stronger algorithms over time. Rate limiting and multi-factor authentication complement hashing for robust security.

Connections

Cryptographic Hash Functions

Password hashing builds directly on cryptographic hash functions as a specialized use case.

Understanding general hash functions helps grasp why password hashing needs extra features like salting and slowness.

Authentication Systems

Password hashing is a core part of authentication, enabling secure user verification.

Knowing password hashing clarifies how authentication protects user identity and access.

One-way Functions in Mathematics

Password hashing uses one-way functions, a concept from math where operations are easy forward but hard backward.

Recognizing this mathematical foundation explains why hashes cannot be reversed, ensuring security.

Common Pitfalls

#1 Storing passwords in plain text in the database.

Wrong approach:

user_password = 'mypassword123'
db.save(user_password)

Correct approach:

from werkzeug.security import generate_password_hash
hashed = generate_password_hash('mypassword123')
db.save(hashed)

Root cause:

Not understanding the security risk of plain text passwords and the need for hashing.

#2 Comparing plain password strings directly instead of hashes.

Wrong approach:

if input_password == stored_password:
allow_access()

Correct approach:

from werkzeug.security import check_password_hash
if check_password_hash(stored_password, input_password):
allow_access()

Root cause:

Misunderstanding that stored passwords are hashed and must be verified by hashing input.

#3 Manually creating and storing salt separately from the hash string.

Wrong approach:

salt = os.urandom(16)
hash = hash_function(salt + password)
db.save(salt, hash)

Correct approach:

from werkzeug.security import generate_password_hash
hash = generate_password_hash(password)
db.save(hash)

Root cause:

Not knowing Werkzeug automatically handles salting and stores it within the hash string.

Key Takeaways

Password hashing scrambles passwords into one-way codes that protect user data even if stolen.

Werkzeug provides easy-to-use functions that handle hashing, salting, and verification securely.

Salting ensures each password hash is unique, preventing attackers from using precomputed tables.

Choosing slow, strong algorithms like PBKDF2 increases security by making attacks costly.

Understanding the internal hash string format helps avoid common mistakes in password storage.

Practice

1. What is the main purpose of using generate_password_hash in a Flask app?

easy

A. To generate random passwords for users

B. To check if a password matches the stored hash

C. To encrypt the entire user database

D. To securely convert a plain password into a hashed version before storing

Solution

1. Step 1: Understand the role of generate_password_hash

   This function takes a plain password and creates a hashed version that is safe to store.

2. Step 2: Differentiate from other functions

   check_password_hash is used to verify passwords, not generate them. Encryption of the whole database or generating random passwords are unrelated.

3. Final Answer:

   To securely convert a plain password into a hashed version before storing -> Option D

4. Quick Check:

   Password hashing = secure storage [OK]

Hint: Hash passwords before storing to keep them safe [OK]

Common Mistakes:

• Confusing hashing with encryption
• Using check_password_hash to create hashes
• Thinking hashing generates random passwords

2. Which of the following is the correct way to import the password hashing functions from Werkzeug?

easy

A. from flask import generate_password_hash, check_password_hash

B. import werkzeug.hash as wh

C. from werkzeug.security import generate_password_hash, check_password_hash

D. import werkzeug.security.hash_password

Solution

1. Step 1: Recall the correct import path

   The password hashing functions are in werkzeug.security, so import them directly from there.

2. Step 2: Check each option

   from werkzeug.security import generate_password_hash, check_password_hash correctly imports both functions. import werkzeug.hash as wh uses a wrong module alias. from flask import generate_password_hash, check_password_hash tries to import from Flask, which is incorrect. import werkzeug.security.hash_password uses a non-existent import path.

3. Final Answer:

   from werkzeug.security import generate_password_hash, check_password_hash -> Option C

4. Quick Check:

   Correct import path = from werkzeug.security import generate_password_hash, check_password_hash [OK]

Hint: Import from werkzeug.security for hashing functions [OK]

Common Mistakes:

• Importing from flask instead of werkzeug
• Using wrong module names or aliases
• Trying to import non-existent functions

3. What will be the output of this code snippet?

from werkzeug.security import generate_password_hash, check_password_hash
hashed = generate_password_hash('mypassword')
print(check_password_hash(hashed, 'mypassword'))
print(check_password_hash(hashed, 'wrongpass'))

medium

A. True\nFalse

B. False\nTrue

C. True\nTrue

D. False\nFalse

Solution

1. Step 1: Understand the hashing and checking process

   The password 'mypassword' is hashed. Then check_password_hash verifies if the given password matches the hash.

2. Step 2: Evaluate the two checks

   Checking with 'mypassword' returns True because it matches. Checking with 'wrongpass' returns False because it does not match.

3. Final Answer:

   True False -> Option A

4. Quick Check:

   Correct password = True, wrong password = False [OK]

Hint: Check returns True only if password matches hash exactly [OK]

Common Mistakes:

• Assuming check_password_hash returns the hash
• Mixing up True and False results
• Not understanding that hashes are one-way

4. Identify the error in this code snippet:

from werkzeug.security import generate_password_hash, check_password_hash
password = 'secret'
hash = generate_password_hash(password)
if check_password_hash(password, hash):
    print('Password matches')

medium

A. Password variable should be hashed twice

B. Arguments to check_password_hash are reversed

C. Missing import for check_password_hash

D. generate_password_hash should be called with bytes, not string

Solution

1. Step 1: Review the function signature of check_password_hash

   The correct order is check_password_hash(hashed_password, plain_password).

2. Step 2: Identify the argument order in the code

   The code passes password first and hash second, which is reversed and causes a logic error.

3. Final Answer:

   Arguments to check_password_hash are reversed -> Option B

4. Quick Check:

   check_password_hash(hashed, password) correct order [OK]

Hint: Pass hashed first, then plain password to check_password_hash [OK]

Common Mistakes:

• Swapping arguments in check_password_hash
• Thinking generate_password_hash needs bytes input
• Forgetting to import check_password_hash

5. You want to store user passwords securely and verify them during login. Which approach correctly uses Werkzeug functions in a Flask app?

hard

A. Hash passwords with generate_password_hash before storing, then verify with check_password_hash

B. Store plain passwords, then use check_password_hash on them

C. Encrypt passwords with generate_password_hash and decrypt during login

D. Store hashed passwords and compare them directly to plain passwords

Solution

1. Step 1: Understand secure password storage

   Passwords must be hashed before storing to protect user data from leaks.

2. Step 2: Use correct verification method

   Use check_password_hash to verify the plain password against the stored hash during login.

3. Step 3: Eliminate incorrect options

   Storing plain passwords is insecure. Hashing is one-way, so decrypting is impossible. Direct comparison of hash and plain password fails.

4. Final Answer:

   Hash passwords with generate_password_hash before storing, then verify with check_password_hash -> Option A

5. Quick Check:

   Hash before store, verify with check_password_hash [OK]

Hint: Always hash before storing; verify with check_password_hash [OK]

Common Mistakes:

• Storing plain passwords
• Trying to decrypt hashes
• Comparing hash and plain password directly