4 ms·
The existence of algorithm confusion attacks shows that it's not nearly as simple as just saying "Reject 'null'". It's a complete minefield, and the fact that t
by growse 3y ago
The existence of algorithm confusion attacks shows that it's not nearly as simple as just saying "Reject 'null'". It's a complete minefield, and the fact that the JWT scheme punts that complexity and "make sure you hold it correctly!" onto the application is bad.
Had the algorithm been standardised to a single value out of band (ie. in the spec), that would have squashed a whole load of vulnerabilities.
- robertlagrant 3y agoWhat whole load is that? The only one I know of is the (silly) existence of the null algorithm.
- growse 3y agoFor example: simply take a valid identity's public key, and use it as the secret to forge a token with alg=hs256. A service receiving this token will use its copy of the public key (by key id) to verify the signature, but because it's being told that it's an HMAC-signed token, will construct an HMAC. Of course this HMAC will verify correctly because both you (the attacker) and the server hold the same public key used. And now the server thinks its a legitimate JWT because the signature is valid. Mixing symmetric and asymmetric cryptography types in the same message scheme is just one of the many ways in which JWT is a bad idea.
- robertlagrant 3y agoI really don't think this is an intrinsic problem at all. I've written JWT-parsing code and it looked for a local public key if it got an RS-algorithm and a local secret if it got an HMAC algorithm. It would be an insane implementation to treat either of them as the other.