Didn’t JWT have a similar thing, where you could specify the algorithm to use and that included “null”?

JWT has two out of the three issues mentioned above:

1. It has the ill-conceived "alg": "none". But this feature made breaking JWT so easy and low stakes, that many libraries have removed this feature completely, or just disabled it by default.

Modern RFCs that mandate JWT use in servers (e.g. RFC 9068) often explicitly forbid this, and the latest BCP for JWT (RFC 8725) recommends that libraries only accept or generate tokens with "none" when the user _explicitly_ requests that. And yet, we're still seeing "alg": "none" vulnerabilities even to this day. I'm not sure if it made sense to support "alg": "none" in the first place, but if we ended up doing that, the RFC should have been much more strict about this.

2. The other issue is mixing up asymmetric and symmetric encryption. You can't embed the HMAC password directly in the user-generated message; but if the library is not built securely, it would just treat the public key itself as the HMAC key when it gets an HMAC alg in the header. This makes forging tokens quite trivial if the library is misconfigured.

JWT is not nearly as bad SAML and its designers learned some important lessons (simpler base format, no canonicalization or embedded signatures), but this is still a design-by-committee standard that didn't properly involve. The full JOSE standard (including JWA) is even worse, but fortunately JWA doesn't get used a lot.

▲

jamesfinlayson a day ago | parent | next [-]

Yeah I wanted to use alg none for some unit tests once (it was easier than setting up the next lowest tier security option) but whichever Java library I was using had completely disabled it. I could see it had been supported at some point but it had been updated so that it couldn't be enabled at all.

▲

talkin 21 hours ago | parent [-]

Yes, that’s a good thing. That alg:none might be easy in tests is not a good reason for a weak mode in the real code and spec.

Been there, done that, wrote the stub/mock and ended up with the better test. :)

	▲	unj 11 hours ago \| parent [-]
		Wasn’t it like a month ago when Sharepoint still accepted alg:none? I guess that proves they’re not using Java :)

▲

huflungdung 17 hours ago | parent | prev [-]

[dead]

▲

bawolff a day ago | parent | prev | next [-]

Yes. JWT also had a bug where some implementations would use the pubkey as an hmac password if you switched the algorithm which is similarly bad.

Specifying the algorithm in the attacker controlled document is a bad design imo.

Still i feel like SAML is much worse. JWT has a few rough edges, but SAML its like everything.

▲

patmorgan23 12 hours ago | parent [-]

Yeah, the standard should have just specified like a sha256 HMAC, when that becomes broken in 20 years we can just do a JWT2 (or invent some new successor standard)

	▲	bawolff 11 hours ago \| parent [-]
		given that md5-hmac isn't even broken despite md5 being broken, it seems unlikely sha256-hmac will fall in 20 years. that said, algorithm agility isn't the primary issue, its whether you want symmetric (hmac) or asymmetric (digital signature). Both have advantages and disadvantages so there is no per-se right answer, it depends on context.

▲

mcpherrinm a day ago | parent | prev | next [-]

https://www.howmanydayssinceajwtalgnonevuln.com/

▲

dwaite a day ago | parent | prev [-]

Yes, but you shouldn't be taking instruction on how to verify the security of a JWT from the JWT itself in the first place. Don't follow an attacker's security steps.