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. Add one script tag to your HTML — that's the entire client integration.

How to Get Started

Add one script tag to your HTML. That's it for the client:

<script
  src="https://tokenforge-api.opensyber.cloud/sdk.js"
  data-api-key="tf_your_api_key"
></script>

The script auto-generates device keys, binds the session, and signs every fetch() request. On the server, add one line of middleware with your API key to verify every request and calculate a 7-signal trust score. For advanced use cases, the npm package @opensyber/tokenforge is also available.