Session Hijacking After MFA: Why Cookies Aren't Enough

Your app has MFA. Your users complete a second factor every time they log in. You're safe, right?

No. MFA protects the login. It does nothing to protect the session that comes after. Once a user authenticates and receives a session cookie, that cookie is the sole proof of identity for every subsequent request. Steal the cookie, and you are the user.

The AiTM Attack

Adversary-in-the-Middle (AiTM) phishing has become the dominant attack against MFA-protected applications. The attacker sets up a reverse proxy between the user and the real login page. The user sees the real UI, enters their password, completes MFA — and the proxy captures the session cookie in real time.

Microsoft reported that AiTM attacks compromised over 10,000 organizations in 2023 alone. The attack works against any session-cookie-based application, regardless of the MFA method used (TOTP, push notifications, SMS).

Why Cookies Are the Problem

A session cookie is a bearer token. Whoever holds it can use it. There is no cryptographic proof that the request comes from the same device that originally authenticated. Cookies can be:

• Stolen via XSS — a single cross-site scripting vulnerability exposes every session
• Captured by AiTM — reverse proxy intercepts the cookie during login
• Exfiltrated by malware — browser info-stealers extract cookies from disk
• Replayed from any device — no device binding, no way to detect theft

The Fix: Device-Bound Sessions

The solution is to bind the session to the device that created it. Instead of a simple cookie, every request carries a cryptographic signature proving it comes from the original device.

TokenForge generates an ECDSA P-256 key pair in the browser using the Web Crypto API. The private key is marked as non-extractable — it cannot be read by JavaScript, exported, or stolen via XSS. Every API request is signed with this key, and the server verifies the signature before processing.

A stolen cookie without the matching device key produces an invalid signature. The server blocks the request and logs a security event.

What About Google DBSC?

Google's Device Bound Session Credentials (DBSC) aims to solve the same problem at the browser level. However, DBSC is Chrome-only, not generally available, and requires browser-level implementation — it's not something you can add to your app today.

TokenForge works in every modern browser (Chrome, Firefox, Safari, Edge) using standard Web Crypto APIs. Initialize the browser device after login and keep the TokenForge credential on your server.

How to Get Started

Initialize the official browser SDK after authenticated login:

const device = await TokenForgeDevice.open({
  bindEndpoint: '/api/v1/auth/device/bind',
  fetch: authenticatedFetch,
});
await device.bindAuthenticatedSession();
const secureFetch = device.wrapFetch(authenticatedFetch);

The SDK auto-generates device keys, binds through your authenticated server endpoint, and signs wrapped fetch requests. The server-only API key verifies requests and calculates trust. The npm package is @opensyber/tokenforge.