Password Hashing (Werkzeug)

Never store plaintext passwords.

If your database leaks and passwords are stored as plaintext, every user account is compromised.

diagram storing a password you can check but never read back mermaid

  flowchart LR
  subgraph Registration
    P1["password"] --> G["generate_password_hash"]
    S["random salt"] --> G
    G --> H["scrypt:32768:8:1$salt$digest"]
    H --> DB[("password_hash column")]
  end
  subgraph Login
    P2["attempted password"] --> C["check_password_hash"]
    DB --> C
    C --> R{"match?"}
    R -->|yes| OK["log the user in"]
    R -->|no| NO["reject -- same message as an unknown user"]
  end

A hash is one-way: there is no arrow back from the stored string to the password. Verification re-runs the same function on the attempt and compares. The salt is what makes two identical passwords store differently, so a stolen database cannot be scanned for repeats.

What the stored value actually looks like

Verified with Werkzeug 3.1.8 — generate_password_hash("hunter2") returns:

text

scrypt:32768:8:1$gVsy0izKtPBP6Etk$4d4278e0ce3f49cf...(128 hex chars)

Three fields separated by $: the algorithm and its parameters (scrypt is the current default), a random 16-character salt, and the digest.

Because the salt is random, hashing the same password twice gives two different strings — and check_password_hash verifies correctly against both. That is the point: two users who happen to pick the same password do not get the same row, so a leaked database cannot be sorted to find the popular passwords.

It also means you can never display a password back to a user, only reset it.

Hashing vs encryption

• Hashing: one-way (you can’t recover original password)
• Encryption: reversible (not what you want for passwords)

Passwords should be stored as:

• salted, slow hashes

Werkzeug helpers

Flask uses Werkzeug, which provides:

• generate_password_hash()
• check_password_hash()

Example:

python

from werkzeug.security import generate_password_hash, check_password_hash
 
hashed = generate_password_hash("my_password")
 
assert check_password_hash(hashed, "my_password") is True
assert check_password_hash(hashed, "wrong") is False

Store in DB

Typically your user model has:

• password_hash column

And you never store the raw password.

Common pitfalls

• Comparing raw passwords in code
• Using fast hashes like MD5/SHA1 for passwords (too fast)
• Logging passwords in debug logs

Werkzeug’s defaults are safe for most projects.