## The JWT "None" Algorithm Bypass In 2015, researcher Tim McLean discovered that multiple JWT libraries — including the most popular ones for Python, Node, Ruby, Java, and PHP — accepted tokens signed with the algorithm `"none"`. This algorithm means: **no signature required**. An attacker could take any valid JWT, change the payload to `"role":"admin"`, set the algorithm to `"none"`, remove the signature entirely, and the library would accept it as valid. Every app using those libraries was vulnerable. Billions of sessions. The fix was a single library update — but only if developers knew to apply it. --- ### Auth0's RS256 → HS256 Confusion (2015) A second class of attack found in the same era: **algorithm confusion**. Many servers use RS256 (asymmetric — public key verifies, private key signs). The public key is often published openly at `/jwks.json` or `/.well-known/openid-configuration`. If an attacker switches the algorithm to HS256 (symmetric — same key signs AND verifies), and signs the token with the **public key** as the HMAC secret — the library uses the public key to verify. Since the attacker also signed with the public key, verification passes. The server is tricked into using its own public key as both the signing secret and the verification key. --- ### Why JWTs Are a Rich Attack Surface | Attack | Prerequisite | |---|---| | Weak secret crack | Know the algorithm is HS256 | | None algorithm | Library doesn't reject alg:none | | Algorithm confusion | Server uses RS256, public key is accessible | | Key injection (JKU/KID) | Server fetches the key from a URL in the token header | The FirstBank ch.4 lab covers weak secret cracking. This module covers the full picture.