Lesson 1 of 3 in Broken Authentication · 5 min left in this chapter
What A Token Trusts
A signed session token proves the server issued it — but only if the server checks the signature the way it should. A verifier that lets the token choose "no signature" is trusting the attacker to be honest about it.
2 min read
Not yet reviewed
The session is a signed token, not a random string in a database. Is that not the more secure option? Nobody can tamper with a signature.
Nobody can tamper with a signature the server *checks properly*. The whole security is in that check. And a token carries, in its own header, a claim about how it should be checked — which is the seam.
The shape of a token
A JSON Web Token is three parts, base64url-encoded and joined by dots: a header that says how it is signed, a payload of claims (who you are, what role you have), and a signature over the first two. The server issues it; on each request it re-computes the signature and, if it matches, trusts the claims.
What the token looks like
{"alg":"HS256"}.{"sub":3,"role":"controller"}.<signature>The claim the header makes
"alg": "HS256" ← "verify me with HMAC-SHA256"The header is not metadata the server sets — it travels *inside the token*, which means it is under the control of whoever holds the token. Including an attacker who wrote their own.
The clause that undoes it
Some verifiers honour an algorithm called none: a token whose header says {"alg":"none"} is accepted with no signature at all. It was meant for tokens passed between trusted systems that sign at another layer. On a session cookie, it means the token can declare itself exempt from the one check that made it trustworthy.
If the server still verifies HS256 tokens correctly, why does accepting none break everything, rather than just adding a harmless option?
alg to none, omit the signature, and write whatever payload they like. The strong check is still there; the attacker just walks around it through the door marked none.