Skip to main content
Web Application Vulnerabilities
CHAPTER 03

Authentication and Session Security

Updated: May 15, 2026
25 min read

# CHAPTER 3

Authentication and Session Security

1. Introduction

The front door of almost every web application is the login screen. If the login mechanism is weak, all other security controls inside the application are irrelevant. Authentication is the process of verifying *who* a user is. Session Management is the process of remembering that user as they click from page to page. In this chapter, we will explore how to build secure login systems, the necessity of strong password hashing, and how to protect session IDs from being stolen by attackers.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define Authentication versus Authorization.
  • Understand why plaintext password storage is catastrophic.
  • Implement secure password hashing using modern algorithms (Bcrypt).
  • Explain the concept of Session Hijacking.
  • Implement secure session management practices in PHP.

3. Beginner-Friendly Explanation

Imagine a VIP nightclub.
  • Authentication: You walk up to the bouncer, show your ID, and give the secret password. The bouncer checks his list and verifies you are allowed in.
  • The Vulnerability (Bad Passwords): If the password to the club is "123456", anyone can guess it and walk in.
  • Session Management: Once inside, you don't want to show your ID every time you order a drink. So, the bouncer gives you a unique, unforgeable wristband (The Session ID).
  • Session Hijacking: If a thief inside the club cuts the wristband off your arm and puts it on theirs, the bartender will think the thief is you and charge your tab.

4. The Golden Rule of Passwords: Hashing

Never, ever store passwords in plaintext. If the database is compromised, the hackers have every user's password. Furthermore, never *encrypt* passwords (because encryption is two-way, meaning the server holds a decryption key that can also be stolen). Passwords must be HASHED. Hashing is a one-way mathematical meat grinder. You put "password123" in, and it outputs a unique string like $2y$10$w.... You save the string. When the user logs in again, you hash their input and see if the two strings match. The server *never* knows the actual password.

5. Multi-Factor Authentication (MFA)

Because humans choose terrible passwords, and because databases get leaked, passwords alone are no longer sufficient. MFA requires two out of three factors:
  1. 1. Something you know: A password.
  1. 2. Something you have: Your smartphone (an authenticator app generating a 6-digit code).
  1. 3. Something you are: A fingerprint or FaceID.
If a hacker steals your password, they still cannot log in because they do not have your physical phone.

6. Securing the Session

Once authenticated, the server generates a Session ID (a long, random string) and sends it to the browser as a Cookie. How do hackers attack this?
  • Session Hijacking: Stealing the cookie via a Cross-Site Scripting (XSS) attack.
  • Session Fixation: The hacker tricks the user into using a specific Session ID that the hacker already knows.
Defenses:
  • Regenerate the Session ID immediately *after* the user successfully logs in.
  • Set the Cookie flags to Secure (HTTPS only) and HttpOnly (Invisible to JavaScript).

7. Mini Project: Build a Secure PHP Login Concept

Let's look at the correct way to handle passwords and sessions in PHP.

Step 1: Registration (Hashing the Password)

php
12345
$password = $_POST['password'];
// NEVER use md5() or sha1() for passwords!
// password_hash automatically generates a secure random Salt and uses Bcrypt.
$hashed_password = password_hash($password, PASSWORD_BCRYPT);
// Save $hashed_password to the database

Step 2: Login & Session Management

php
123456789101112
$login_attempt = $_POST['password'];
// Fetch the $hashed_password from the database based on username
if (password_verify($login_attempt, $hashed_password)) {
    // Login successful!
    session_start();
    // CRITICAL: Prevent Session Fixation by regenerating the ID!
    session_regenerate_id(true); 
    $_SESSION['user_id'] = $user_id;
    echo "Welcome to the dashboard.";
} else {
    echo "Invalid credentials.";
}

8. Real-World Scenarios

A popular forum software had a vulnerability in its "Forgot Password" logic. When a user requested a password reset, the application generated a random 4-digit PIN and emailed it to the user. However, the application did not implement "Rate Limiting." A hacker requested a password reset for the Administrator account, and then used a script to try all 10,000 possible PIN combinations (0000 to 9999) in less than 30 seconds. The server accepted the correct PIN, and the hacker took over the entire forum. Proper rate limiting (locking the account after 5 failed attempts) would have prevented this brute-force attack entirely.

9. Best Practices

  • Generic Error Messages: When a user logs in incorrectly, never say "Password incorrect" or "Username not found." This tells an attacker whether a specific email address exists in your database (User Enumeration). Always use a generic message like: "Invalid username or password."
If you are storing user credentials, you have a legal obligation under frameworks like GDPR or CCPA to protect that data using industry-standard cryptography. Storing passwords in plaintext or using deprecated algorithms like MD5 can be considered gross negligence, leading to severe regulatory fines following a data breach.

11. Exercises

  1. 1. Explain why hashing passwords using Bcrypt is fundamentally more secure than encrypting passwords using AES-256.
  1. 2. What is Session Fixation, and what specific PHP function neutralizes this threat during the login process?

12. FAQs

Q: Should I force users to change their passwords every 90 days? A: Actually, no. Modern NIST guidelines (National Institute of Standards and Technology) advise *against* forced arbitrary password expiration. When forced to change passwords frequently, users resort to predictable patterns (e.g., PasswordFall2024!, PasswordWinter2024!), which makes them easier to guess. Only force a change if there is evidence of a compromise.

13. Interview Questions

  • Q: Describe the authentication workflow for a secure web application, detailing the transition from verifying credentials to establishing a secure, stateful session.
  • Q: A developer has implemented a session cookie but failed to set the HttpOnly flag. Detail the specific attack vector this exposes and how an attacker would exploit it to achieve account takeover.

14. Summary

In Chapter 3, we secured the front door. We established that passwords must be hashed using robust, salted algorithms like Bcrypt, and never stored in plaintext or reversibly encrypted. We introduced Multi-Factor Authentication as the necessary evolution of credential security. Finally, we protected the post-login state by properly regenerating Session IDs to defeat fixation attacks and securing cookies against client-side theft.

15. Next Chapter Recommendation

The front door is secure, but what if the attacker slips a malicious note under the door directly to the database? Proceed to Chapter 4: SQL Injection Awareness.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·