Introduction

Password handling means managing passwords safely throughout their life cycle: registration, login, storage, reset, update, verification, and account protection.

Passwords are one of the most common ways users prove their identity. Because passwords protect accounts and private data, developers must handle them carefully.

A secure application should never store plain-text passwords, never expose passwords in logs, never send passwords carelessly, and never hardcode credentials in source code.

Easy Real-Life Example

Locker Security:
- Do not leave key openly
- Do not share key carelessly
- Use strong lock
- Change lock if key is lost
- Add extra security for valuable items

Password Security:
- Do not store plain-text passwords
- Do not expose passwords in logs
- Use secure password hashing
- Support password reset safely
- Use MFA for sensitive accounts

Passwords are like digital keys. If they are handled poorly, accounts and data become unsafe.

What is Password Handling?

Password handling is the set of practices used to safely collect, verify, store, reset, update, and protect passwords.

It includes both user-facing behavior and backend security controls.

Why Password Handling is Important

Passwords protect user accounts. If passwords are handled incorrectly, attackers may gain access to private information, admin features, financial data, student records, or business systems.

What Can Go Wrong with Poor Password Handling?

Principle 1: Never Store Plain-Text Passwords

Plain-text password storage means saving the actual readable password in a database or file.

This is extremely unsafe because anyone who gains database access can read all passwords directly.

Bad Practice

username: "student01"
password: "MyPassword123"

Better Practice

username: "student01"
passwordHash: "stored_secure_password_hash"

The system should store a secure password hash, not the original password.

Principle 2: Use Password Hashing

Hashing converts a password into a fixed output value using a one-way process.

One-way means the application should not be able to convert the hash back into the original password.

User password:
MyPassword123

Hashing process:
MyPassword123 → secure hash value

Database stores:
secure hash value

During login, the entered password is processed again and compared with the stored hash.

Password Verification Flow

Registration:
1. User creates password.
2. System validates password.
3. System hashes password using secure password hashing.
4. System stores the password hash.

Login:
1. User enters password.
2. System hashes the entered password.
3. System compares it with stored password hash.
4. If they match, authentication succeeds.

Hashing vs Encryption

Hashing and encryption are different. Students must understand this difference clearly.

Principle 3: Use Slow Password Hashing Algorithms

Password hashing should be intentionally slow enough to make guessing attacks more difficult.

General fast hash functions are not ideal for password storage because attackers can try many guesses quickly.

In real projects, developers should use trusted libraries and framework-supported password hashing functions instead of creating custom password hashing logic.

Principle 4: Use Salt

A salt is a unique random value added to each password before hashing.

Salting helps ensure that two users with the same password do not have the same stored hash.

User A password:
Password123

User A salt:
randomSaltA

User A hash:
HASH(Password123 + randomSaltA)


User B password:
Password123

User B salt:
randomSaltB

User B hash:
HASH(Password123 + randomSaltB)

Even though both users used the same password, their stored hashes become different because their salts are different.

Principle 5: Understand Pepper

A pepper is an additional secret value used with password hashing as defense in depth.

Unlike a salt, which is usually stored with the password hash, a pepper should be protected separately in a secure configuration or secrets management system.

Principle 6: Validate Password Input

Password fields should be validated during registration, login, password update, and reset.

Principle 7: Encourage Strong Passwords

Strong passwords reduce the chance of successful guessing attacks.

Modern password guidance often favors longer passwords and passphrases instead of forcing confusing short patterns that users cannot remember.

Principle 8: Do Not Log Passwords

Logs are useful for debugging and monitoring, but passwords must never be written into logs.

Bad Logging

LOG "Login attempt: email=student@example.com password=MyPassword123"

Safer Logging

LOG "Login attempt failed for user identifier."

Log useful security events, but avoid storing secrets or sensitive values.

Principle 9: Never Hardcode Passwords

Hardcoding passwords means placing passwords directly inside source code.

Bad Practice

databasePassword = "AdminPassword123"

Better Practice

databasePassword = GET_SECRET("DATABASE_PASSWORD")

Credentials should be stored in secure configuration or secret management systems, not inside code.

Principle 10: Use Safe Login Error Messages

Login error messages should not reveal whether the username exists or whether only the password was wrong.

Unsafe Error Messages

"Email exists but password is wrong."
"User not found."

Safer Error Message

"Invalid username or password."

A generic error message gives less useful information to attackers.

Password Reset Basics

Password reset is a sensitive feature because it can be misused to take over accounts.

Bad Reset Flow

User clicks "Forgot Password"
System emails the old password to the user

Better Reset Flow

User clicks "Forgot Password"
System sends temporary reset link
User creates a new password
System hashes and stores the new password
Reset link becomes invalid

Passwords and MFA

Passwords can be stolen, guessed, reused, or leaked. Multi-Factor Authentication, or MFA, adds another layer of protection.

Password-only login:
User enters password.

MFA login:
User enters password.
User also verifies using OTP, authenticator app, security key, or another factor.

MFA is especially useful for admin accounts, sensitive applications, financial operations, and high-risk actions.

Login Attempt Protection

Password systems should be protected from repeated guessing.

Password Handling and Sessions

After a user successfully logs in, the application usually creates a session or token.

The password should not be repeatedly stored or sent with every request. Instead, the application should use secure session or token handling after authentication.

Good flow:
1. User enters password during login.
2. Password is verified.
3. Secure session or token is created.
4. Future requests use the session or token.
5. Password is not sent again with every request.

Real-World Example: E-Commerce Password Handling

Student-Friendly Example: Student Portal Password Handling

Student Portal Password Rules:

Registration:
- Student creates password.
- System validates password.
- System stores secure password hash.

Login:
- Student enters password.
- System verifies password against stored hash.
- System creates secure session.

Forgot Password:
- Student requests reset.
- System sends temporary reset link or code.
- Student creates new password.
- System stores new password hash.

Example: Bad Password Storage

FUNCTION registerUser(email, password)
    SAVE email and password in database
    RETURN "Registration successful"
END FUNCTION

This is unsafe because it stores the readable password directly.

Example: Improved Password Storage Concept

FUNCTION registerUser(email, password)
    IF email is empty OR password is empty THEN
        RETURN "Invalid registration details"
    END IF

    IF password does not meet password rules THEN
        RETURN "Password does not meet requirements"
    END IF

    passwordHash = SECURE_PASSWORD_HASH(password)

    SAVE email and passwordHash in database

    RETURN "Registration successful"
END FUNCTION

This version stores a password hash instead of the original password.

Example: Password Login Verification Concept

FUNCTION loginUser(email, password)
    IF email is empty OR password is empty THEN
        RETURN "Invalid username or password"
    END IF

    userAccount = FIND account by email

    IF userAccount does not exist THEN
        RETURN "Invalid username or password"
    END IF

    IF VERIFY_PASSWORD(password, userAccount.passwordHash) is false THEN
        RETURN "Invalid username or password"
    END IF

    CREATE secure session

    RETURN "Login successful"
END FUNCTION

This version uses a generic error message and verifies the password against the stored hash.

Password Handling Checklist

Common Beginner Mistakes

Best Practices for Password Handling

Prerequisites Before Learning Password Handling

Students should understand the following topics before learning password handling deeply:

Trace Table Example: Password Login

FUNCTION loginUser(email, password)
    IF email is empty OR password is empty THEN
        RETURN "Invalid username or password"
    END IF

    userAccount = FIND account by email

    IF userAccount does not exist THEN
        RETURN "Invalid username or password"
    END IF

    IF VERIFY_PASSWORD(password, userAccount.passwordHash) is false THEN
        RETURN "Invalid username or password"
    END IF

    RETURN "Login successful"
END FUNCTION

Practice Activity: Improve Password Handling

Improve the following pseudocode by applying secure password handling practices.

FUNCTION register(email, password)
    SAVE email
    SAVE password
    RETURN "User registered"
END FUNCTION

Sample Improved Version

FUNCTION register(email, password)
    IF email is empty OR password is empty THEN
        RETURN "Invalid registration details"
    END IF

    IF password does not meet password rules THEN
        RETURN "Password does not meet requirements"
    END IF

    passwordHash = SECURE_PASSWORD_HASH(password)

    SAVE email
    SAVE passwordHash

    RETURN "User registered"
END FUNCTION

Practice Test Cases

Mini Quiz

Interview Questions on Password Handling Basics

Quick Summary