What is the difference between session token theft and password theft?

Password theft steals the credential used to create a session. Session token theft steals the session itself — the cookie or bearer token issued after login. The critical difference is that multi-factor authentication only runs during login, so a stolen session token bypasses MFA entirely. It was already satisfied when the token was minted. This is why session theft became the dominant account-takeover method in 2026.

Does MFA protect against stolen session cookies?

No. MFA is a login-time control and a stolen session token skips login. The attacker replays a valid, already-authenticated token. Protection requires either short session lifetimes, device-bound tokens using proof-of-possession, anomaly detection on session reuse from a new IP or device fingerprint, or explicit session revocation. Adding a second factor changes nothing about a cookie that has already been issued.

Which is worse, a leaked API key or a stolen session?

A leaked API key is usually worse in blast radius and better in recoverability. Keys often carry broad programmatic scope, no MFA, no interactive audit trail, and can run at machine speed until revoked. But keys are individually revocable in seconds and rotation is a routine operation. A stolen session grants whatever the human can do in the UI — including reading conversation history and changing account settings — and users rarely know how to revoke sessions.

How do I revoke each type of compromise?

Password theft: change the password, then explicitly sign out all sessions, because a password change alone does not always invalidate live sessions. Session theft: use sign-out-everywhere or session revocation, and remove the malware first or the new session gets stolen too. API key leak: revoke the specific key at the provider, rotate to a new one, then audit usage logs for the exposure window. Only the API key case is a clean single action.

Quick Answer

Session Theft vs Password Theft vs API Key Leak 2026

Published: August 31, 2026

The Short Answer

	Password theft	Session token theft	API key leak
What’s stolen	Login credential	Post-login cookie / bearer token	Long-lived programmatic secret
Common vector	Phishing, reuse, breach dumps	Infostealer malware, XSS, AitM proxy	Git commits, logs, CI vars, pasted into chat
Stopped by MFA?	✅ Usually	❌ No	❌ No (MFA doesn’t apply)
Attacker gets	Ability to log in	Everything the user has, right now	Whatever scope the key carries
Typical lifetime	Until changed	Until session expiry or revocation	Until revoked — often years
Revocation	Change password + sign out all	Sign out everywhere (after cleaning device)	Revoke + rotate key
Detection difficulty	Low	High	Medium

Last verified: August 31, 2026.

Why This Distinction Suddenly Matters

The industry spent a decade winning the password war. Password managers went mainstream, MFA became default-on at most major providers, and breach-dump credential stuffing stopped being reliably profitable.

Attackers responded rationally: they stopped attacking the front door and started stealing what sits behind it.

August 2026 supplied the textbook case. Anthropic began emailing Claude users to warn that infostealer malware on their own machines had captured active Claude login sessions, which attackers replayed to consume usage limits. Anthropic’s remedy — forced sign-out, removal of saved payment methods, refunds of unauthorized charges — is the correct response profile, and notably contains no mention of passwords. Passwords were never involved. (Full detail in our Claude session hijacking writeup.)

1. Password Theft — The Solved-ish Problem

How it works: phishing pages, credential reuse across breached sites, or bulk dumps tested against your login endpoint.

Why it’s now the weakest of the three: MFA genuinely works here. An attacker with your password and no second factor is stuck at the prompt.

The residual risk is adversary-in-the-middle phishing, which proxies the real login page, harvests the password and the resulting session token in one flow. Note what that actually is: an AitM attack is a password attack that upgrades itself into a session-theft attack, because the session token is the part worth having.

Revocation: change the password — then explicitly sign out all sessions. A password change does not universally invalidate live tokens, and assuming it does is the most common recovery mistake.

2. Session Token Theft — The Dominant Threat

How it works: malware on the endpoint reads the browser cookie store. The Lumma/Redline/Vidar family and their forks sweep cookies, saved credentials, wallets and clipboard contents in a single pass and exfiltrate in seconds. XSS and AitM proxies achieve the same result without needing local code execution.

Why it defeats MFA: MFA is evaluated once, at login. The token issued afterwards is the proof that MFA succeeded. Copy the token, skip the check.

Why detection is hard: replayed sessions look like the legitimate user. Same account, valid token, plausible user agent. Detection requires behavioural signals — impossible-travel geolocation, device-fingerprint mismatch, concurrent-session anomalies, usage-rate spikes. Most consumer products ship none of these.

Why AI accounts are prime targets in 2026: hijacked usage limits are directly resellable on grey-market “shared account” services; conversation histories are dense with pasted API keys, connection strings and unreleased code; and AI chat products deliberately keep users signed in for weeks because re-authentication kills the habit loop.

Revocation: clean the machine first, then sign out everywhere. Reversing that order hands the attacker a fresh token.

3. API Key Leak — Widest Blast Radius, Cleanest Fix

How it works: the key ends up somewhere it shouldn’t. Committed to a repo, printed into a log, stored in a CI variable that a build script echoes, or pasted into a chat window that later gets compromised via route 2.

Why it’s dangerous: no MFA applies, scope is often far broader than necessary, and machine-speed abuse can run up five figures of inference spend before a billing alert fires.

Why it’s the most recoverable: keys are designed to be revoked. It’s a single API call or dashboard click, rotation is routine, and provider usage logs give you a precise exposure window.

The compounding risk worth naming: routes 2 and 3 chain. A stolen session gives an attacker your provider console, and the console mints new API keys. Revoking keys without revoking sessions is theatre.

The Practical Hierarchy

If you have limited effort to spend, spend it in this order:

Endpoint hygiene. Every one of these routes is dramatically worse on a compromised machine, and route 2 requires one.
Session revocation literacy. Know where “sign out of all devices” lives for your top ten accounts before you need it.
Key scoping and rotation. Narrow scopes, short lifetimes, automated rotation. Never a long-lived key with account-wide scope.
MFA. Still necessary, still insufficient. It closes route 1 and nothing else.

The direction of travel for providers is device-bound tokens — cryptographically binding a session to hardware so a copied cookie is useless elsewhere. The standards exist. Adoption across consumer AI products as of August 2026 remains thin, which is precisely why route 2 is having such a good year.