4 ms·
I point out numerous cases where the server made a mistake in verifying the algorithm specified by the client. This is the point of reducing the complexity of t
by kevinburke 9y ago
I point out numerous cases where the server made a mistake in verifying the algorithm specified by the client. This is the point of reducing the complexity of the interaction
If you are using JWT and someone breaks SHA2, you still have to worry about downgrade attacks. To evade downgrade attacks, you'll have to detect the protocol the client sends, and reject tokens that specify SHA2 or below. Or, roughly the same position you'd be in with one good algorithm: still in need of a backwards incompatible upgrade
- politician 9y agoThis concern was always supposed to be handled by algorithm whitelists. The _intent_ was that services would consult a whitelist of algorithms before accepting a particular JWT. The idea was certainly not that services blindly accept any token from every algorithm shipped in the library. Your browser supports TLS 1.0, should you throw it out? > If someone breaks SHA2... JWT has a built-in mechanism for handling this: expirations.
- kevinburke 9y agoThere's no "better TLS" out there for shipping a tool that connects to millions of different servers. There are many better options than JWT. Unlike JWT, hundreds of the world's best security engineers at various browser companies are working on mitigating the situation as well as possible.
- politician 9y agoIndeed, however, consider that servers can and do limit which TLS versions and cipher suites they accept.
- joepie91_ 9y agoExpirations are not really relevant to this. It won't prevent a user from forging new tokens with a different expiration (using a broken algorithm), nor will it somehow magically make the original token unreadable. The expiration is just an additional value in the payload that the implementation is supposed to check against.