Authentication & Web Security Demo

CS 360 — Password Storage, Session Cookies, Third-Party Tracking, Same-Origin Policy & CORS

Setup & Running

Enter the demo folder: cd auth-demo

Run both servers: ./run.sh

Open http://localhost:5050 — main app on port 5050, third-party server on port 5051

Two servers run on different ports to demonstrate cross-origin behavior (SOP, CORS, third-party cookies). A SQLite file auth_demo.db is created automatically. Use the Reset Database button in Step 2 to clear all users between demos.

Not logged in

Register a User

Choose a hashing scheme, then register. See exactly what gets stored.

MD5 — No Salt

Insecure. Deterministic, no randomness. Vulnerable to rainbow tables.

SHA-256 + Random Salt

Secure. Random salt makes each hash unique, even for identical passwords.

SHA-256 + Salt: A random 16-byte salt is generated per user. The salt is prepended to the password before hashing: SHA-256(salt + password). The salt is stored alongside the hash and is not secret — its sole purpose is to defeat precomputed lookup tables.

Username Password

Database Contents

What actually gets persisted. Note how MD5 users with the same password have identical hashes.

Identical MD5 hashes detected (highlighted in red). Two users share the same password — visible without cracking anything.

#	Username	Scheme	Salt	Stored Hash
No users yet. Register some above.

Key observation: With SHA-256 + Salt, the salt column is filled and each user's hash is unique even if they chose the same password. With MD5 (no salt), two identical passwords produce identical hashes — revealing shared credentials at a glance.

Test Login (with Session Cookie)

Verify a password against the stored hash. On success, the server sets a session cookie.

Username Password

Rainbow Table Attack on MD5

Precomputed lookup tables instantly reverse unsalted MD5 hashes for common passwords.

How a rainbow table attack works: Because MD5 is deterministic and fast, an attacker precomputes a table of password → hash mappings offline. When a password database is leaked, each MD5 hash is looked up in the table — no brute force needed. A salt defeats this because the attacker would need a separate table per salt value.

Precomputed table (25 common passwords)

Loading…

Crack a single hash

Paste any MD5 hash (copy one from the Database table above, or use an MD5 user's hash).

MD5 Hash to crack

Bulk attack all MD5 users

Attacks every MD5 account in the database simultaneously. SHA-256 + salted accounts are immune because each salt would require its own table.

Why salting works: An attacker who steals your database sees each SHA-256 hash paired with a unique salt. To crack user A's password they would need a rainbow table for A's specific salt — and then a completely separate table for user B's salt, and so on. The cost grows linearly with the number of users, making bulk attacks computationally infeasible.

Session Cookies

After login, the server sets a session cookie. See what the browser sends on each request.

How cookie-based auth works: On login, the server creates a random session token, stores it in a database, and sends Set-Cookie: session_token=<token>. The browser attaches this cookie to every request to the same origin — no password re-entry needed.

Try it: Log in using Step 3 above, then click the buttons below to see what the browser sends automatically.

Active sessions in database

The server stores each session token → username mapping. This is what gets looked up on every request.

Username	Session Token	Created
No sessions yet.

Cookie Inspector & Attributes

View, create, and experiment with cookie security attributes.

Cookie attributes control security: HttpOnly — JS cannot read the cookie (prevents XSS theft). Secure — only sent over HTTPS. SameSite — controls cross-site sending (Strict / Lax / None). Max-Age — expiry in seconds.

Current cookies (document.cookie)

Only non-HttpOnly cookies are visible to JavaScript. HttpOnly cookies are hidden here but still sent by the browser.

Name	Value	Actions

Set a custom cookie

Name Value

SameSite Max-Age (sec) Path

HttpOnly (JS won't see it!)

Secure (HTTPS only)

Third-Party Cookies

See how a different origin (port 5051) sets tracking cookies while you're on port 5050.

Third-party cookies are set by a domain different from the one in the address bar. You're on https://cs360umass.org, but resources from https://tp.cs360umass.org can set their own cookies. Ad networks use this to track you across sites. Modern browsers increasingly block these.

Tracking pixel (invisible image)

A 1×1 transparent GIF loaded from https://tp.cs360umass.org/pixel.gif. The third-party server sets a tracking_id cookie when delivering it.

Third-party iframe

An iframe loading https://tp.cs360umass.org/embed. It sets its own cookies — visible inside the iframe but not to your JS on :5050.

Why can't I read their cookies? document.cookie only shows cookies for this origin (:5050). The tracking cookies from :5051 are invisible to your JavaScript. Check DevTools → Application → Cookies → https://tp.cs360umass.org to see them.

Same-Origin Policy & CORS

The browser's most important security boundary — and the standard mechanism to relax it.

Same-Origin Policy (SOP): The browser blocks JavaScript from reading responses from a different origin. Two URLs share an origin only if they match in scheme, host, and port. localhost:5050 and localhost:5051 are different origins.

CORS (Cross-Origin Resource Sharing): The server's opt-in mechanism. By including Access-Control-Allow-Origin in the response, the third-party server tells the browser "I trust this other origin to read my data."

URL A	URL B	Same Origin?	Why?
https://cs360umass.org/a	https://cs360umass.org/b	Yes	Same scheme, host, port
https://cs360umass.org	https://tp.cs360umass.org	No	Different origin
http://example.com	https://example.com	No	Different scheme
http://example.com	http://api.example.com	No	Different host

Demo: Same-origin request (5050 → 5050)

Same origin — always works, no CORS needed.

Demo: Cross-origin WITHOUT CORS (blocked!)

Fetches from https://tp.cs360umass.org/api/no-cors. No Access-Control-Allow-Origin header → browser blocks your JS from reading the response.

The request STILL reaches the server! SOP blocks reading the response, not sending the request.

Demo: Cross-origin WITH CORS (allowed)

The server on https://tp.cs360umass.org includes Access-Control-Allow-Origin: https://cs360umass.org — the browser lets your JS read the data.

Demo: CORS + Credentials (cookies sent cross-origin)

Cross-origin fetch() does NOT send cookies by default. You need credentials: 'include' AND the server must respond with Access-Control-Allow-Credentials: true (and must NOT use wildcard *).