Hacker News new | past | comments | ask | show | jobs | submit login

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




This 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.


Expirations 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.


There'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.


Indeed, however, consider that servers can and do limit which TLS versions and cipher suites they accept.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: