User model with password in Flask - Deep Dive

Overview - User model with password

What is it?

A User model with password in Flask is a way to represent users in a web application, including their login credentials. It stores user information like username and a secure version of their password. This model helps the app know who is logged in and keeps passwords safe by not storing them as plain text. It is essential for managing user accounts and authentication.

Why it matters

Without a proper User model that handles passwords securely, user data can be exposed or stolen, leading to privacy breaches and loss of trust. It solves the problem of safely storing and verifying user credentials so only authorized people can access their accounts. Without it, websites would be vulnerable to attacks and users would risk their personal information.

Where it fits

Before learning this, you should understand basic Python classes and Flask app structure. After this, you can learn about user authentication flows, session management, and securing routes. This topic is a foundation for building login systems and user management in Flask web apps.

Mental Model

Core Idea

A User model with password securely stores user info and verifies identity without exposing the actual password.

Think of it like...

It's like a locked mailbox where the key (password) is never shown, only tested to open the box (user account).

┌───────────────┐
│   User Model  │
├───────────────┤
│ username      │
│ password_hash │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Password Hash │
│ (secure lock) │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Define Basic User Model Class

Concept: Introduce how to create a simple User class to hold user data.

In Flask, start by defining a User class with attributes like username and password. This class acts as a blueprint for user objects. class User: def __init__(self, username, password): self.username = username self.password = password # Not secure yet This stores the password directly, which is unsafe.

Result

You can create user objects with username and password, but passwords are stored as plain text.

Understanding how to represent users as objects is the first step before adding security.

2

Foundation

Understand Password Security Basics

Concept: Explain why storing plain passwords is dangerous and introduce hashing.

Passwords should never be saved as plain text because if the database leaks, attackers get all passwords. Instead, we use hashing: a one-way process that turns passwords into fixed strings that can't be reversed. Hashing means even if someone sees the stored data, they can't get the original password.

Result

Learners realize the need for password hashing to protect user data.

Knowing why plain passwords are unsafe motivates using secure methods.

3

Intermediate

Implement Password Hashing with Werkzeug

🤔Before reading on: do you think hashing passwords once is enough, or should you also check hashes carefully? Commit to your answer.

Concept: Use Flask's Werkzeug library to hash passwords and verify them safely.

Werkzeug provides functions to hash passwords and check them: from werkzeug.security import generate_password_hash, check_password_hash class User: def __init__(self, username, password): self.username = username self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) This way, passwords are stored as hashes, and verification compares hashes.

Result

User objects store hashed passwords and can verify input passwords securely.

Using trusted libraries for hashing avoids common security mistakes.

4

Intermediate

Integrate User Model with Flask-Login

🤔Before reading on: do you think the User model needs to implement special methods for Flask-Login? Commit to your answer.

Concept: Make the User model compatible with Flask-Login to manage user sessions.

Flask-Login requires the User class to have methods like is_authenticated and get_id: from flask_login import UserMixin class User(UserMixin): def __init__(self, id, username, password): self.id = id self.username = username self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) UserMixin provides default implementations needed for login management.

Result

User model works smoothly with Flask-Login for handling logged-in users.

Understanding integration points helps build full authentication systems.

5

Advanced

Store Users in Database with SQLAlchemy

🤔Before reading on: do you think storing passwords in the database requires special column types or just plain strings? Commit to your answer.

Concept: Use SQLAlchemy ORM to save User objects with hashed passwords in a database.

Define a User model class inheriting from SQLAlchemy's Base: from flask_sqlalchemy import SQLAlchemy db = SQLAlchemy() class User(db.Model): id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(150), unique=True, nullable=False) password_hash = db.Column(db.String(128), nullable=False) def set_password(self, password): self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) This stores hashed passwords safely in the database.

Result

Users with hashed passwords are stored persistently and securely.

Knowing how to combine ORM and hashing is key for real apps.

6

Advanced

Handle Password Updates and Verification

🤔Before reading on: do you think updating a password requires re-hashing or can you reuse the old hash? Commit to your answer.

Concept: Ensure password changes re-hash the new password and verify input correctly.

When users change passwords, always hash the new password before saving: user.set_password('newpassword') db.session.commit() Verification uses check_password method to compare input with stored hash. Never store or compare plain passwords directly.

Result

Password updates remain secure and verification works as expected.

Understanding password lifecycle prevents security holes during updates.

7

Expert

Avoid Common Security Pitfalls in Password Handling

🤔Before reading on: do you think salting is automatic with Werkzeug's generate_password_hash or must be done manually? Commit to your answer.

Concept: Learn subtle security details like salting, hashing algorithms, and timing attacks.

Werkzeug's generate_password_hash automatically adds a salt, making hashes unique even for same passwords. Avoid storing passwords with weak hashes like MD5. Use constant-time comparison (check_password_hash) to prevent timing attacks. Also, never reveal if username or password was wrong separately to avoid information leaks.

Result

Password handling is robust against advanced attack techniques.

Knowing these details protects apps from subtle but serious vulnerabilities.

Under the Hood

When a password is set, generate_password_hash creates a salted hash using a strong algorithm like PBKDF2. The salt is random and stored inside the hash string. When verifying, check_password_hash extracts the salt and algorithm info from the stored hash and applies the same process to the input password. If the results match, the password is correct. This process ensures passwords are never stored or compared in plain text, protecting against leaks and brute force attacks.

Why designed this way?

This design balances security and usability. Salting prevents attackers from using precomputed tables (rainbow tables). Using strong hashing algorithms slows down brute force attempts. Storing the salt inside the hash string simplifies storage and verification. Werkzeug chose this approach to provide secure defaults that are easy for developers to use without deep cryptography knowledge.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ User inputs   │──────▶│ generate_     │──────▶│ Store hash    │
│ password      │       │ password_hash │       │ with salt     │
└───────────────┘       └───────────────┘       └──────┬────────┘
                                                      │
                                                      ▼
┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ User inputs   │──────▶│ check_        │──────▶│ Compare hash  │
│ password      │       │ password_hash │       │ securely      │
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think storing hashed passwords means you can recover the original password? Commit to yes or no.

Common Belief: If passwords are hashed, you can still get the original password back from the hash.

Reality: Hashing is one-way; you cannot reverse it to get the original password.

Why it matters: Believing you can reverse hashes leads to insecure practices like storing reversible encryption or plain text passwords.

Quick: Do you think using simple hashing like MD5 is secure enough for passwords? Commit to yes or no.

Common Belief: Any hash function like MD5 or SHA1 is good enough for password storage.

Reality: MD5 and SHA1 are fast and vulnerable to attacks; strong slow hashes like PBKDF2 or bcrypt are needed.

Why it matters: Using weak hashes makes it easy for attackers to crack passwords quickly.

Quick: Do you think you should store the password hash and the salt separately? Commit to yes or no.

Common Belief: Salt must be stored separately from the password hash.

Reality: Modern hash functions store the salt inside the hash string automatically.

Why it matters: Trying to manage salt separately complicates code and can cause errors or security holes.

Quick: Do you think comparing password hashes with '==' is safe? Commit to yes or no.

Common Belief: You can compare password hashes using simple equality operators.

Reality: Simple equality checks can leak timing information; constant-time comparison functions are needed.

Why it matters: Timing attacks can reveal password info if comparisons are not done securely.

Expert Zone

1

Werkzeug's generate_password_hash uses PBKDF2 with SHA256 by default, which balances security and performance.

2

The password hash string encodes algorithm, iterations, salt, and hash, enabling flexible upgrades without breaking verification.

3

Flask-Login's UserMixin provides default methods but real apps often extend User models with roles and permissions for fine-grained access control.

When NOT to use

For extremely high-security applications, consider using dedicated authentication services or hardware security modules instead of rolling your own password handling. Alternatives include OAuth providers or multi-factor authentication systems.

Production Patterns

In production, User models are combined with database migrations, password reset flows, email verification, and rate limiting login attempts. Password hashing parameters are tuned for current hardware capabilities and updated periodically.

Connections

Hash Functions in Cryptography

Builds-on

Understanding cryptographic hash functions helps grasp why password hashing is secure and how salts prevent attacks.

Session Management in Web Applications

Builds-on

User models with passwords are the foundation for managing user sessions and access control in web apps.

Physical Locks and Keys

Analogy-based

Knowing how physical locks use unique keys helps understand why passwords are hashed and salted to protect access.

Common Pitfalls

#1 Storing passwords as plain text in the database.

Wrong approach:

user.password = 'mypassword123'
db.session.add(user)
db.session.commit()

Correct approach:

user.set_password('mypassword123')
db.session.add(user)
db.session.commit()

Root cause:

Misunderstanding that passwords must be hashed before storage to protect user security.

#2 Comparing passwords using '==' instead of secure hash check.

Wrong approach:

if user.password_hash == input_password:
login_user(user)

Correct approach:

if user.check_password(input_password):
login_user(user)

Root cause:

Not realizing that password hashes must be verified with special functions to avoid security risks.

#3 Reusing the same password hash when updating password without re-hashing.

Wrong approach:

user.password_hash = new_password
# saved directly without hashing

Correct approach:

user.set_password(new_password)
# hashes before saving

Root cause:

Forgetting to hash new passwords leads to storing plain text or invalid hashes.

Key Takeaways

Never store plain text passwords; always hash them with a salt using trusted libraries.

Use Werkzeug's generate_password_hash and check_password_hash for secure password handling in Flask.

Integrate User models with Flask-Login by implementing required methods for smooth authentication.

Store password hashes in the database, not passwords, and always re-hash when updating passwords.

Be aware of subtle security details like salting, hashing algorithms, and timing-safe comparisons to protect users.