Hacker News Reader

Comment by fcvarela | Hacker News Reader

"Send a header that specifies the "none" algorithm be used"

Why would an issuer ever let a client decide what algo to use?

"Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key."

Again, under what circumstances would a header be used by the client to ask for a specific implementation?

What about encrypted client side cookies - would you let the client "send a header" to specify which key to use???

The only problems you highlighted are serious input validation issues and a naive, broken trust model.

View on HN

> Why would an issuer ever let a client decide what algo to use?

JWT, like SAML, is made to support separate identity providers and the service providers. In the spirit of generality, this means the identity provider(s) could be from a different vendor, operated by a different organization. E.g., you could let users access their account on your service based a token issued from Google. But that means Google chooses the algorithm, not you!

And it's a standard, so you don't have to write any code of your own. Just import the right middleware for your framework and you're set!

So the temptation is there for library authors to support all the defined algorithms, and just enable everything by default to be as compatible as possible - after all, you can just look at the header to see which algorithm to use!

> The only problems you highlighted are serious input validation issues and a naive, broken trust model.

If these things are suggested in the standard and promptly followed by major implementations, then the standard isn't very good.

But they aren't. Nobody is suggesting to anybody to use NONE as the algorithm.

EDIT: the secondary spec describing the algorithms is at least clear on the use of none, I missed that at first: Implementations that support Unsecured JWSs MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected. Implementations MUST NOT accept Unsecured JWSs by default.

https://www.rfc-editor.org/rfc/rfc7518.txt

Still, my point about it missing from RFC7115 stands.

---- Original comment ---------

The standard says you should support NONE as the algorithm and that you should use the algorithm the client sends you, all the while completely failing to mention the issues with that, both in its Security Considerations section (which mentions even more "obvious" things like "use keys with high entropy") and in the description of the algorithm to decode a token (which initial implementers probably relied upon to get to a "correct" implementation). Sorry, that is a failure of the spec as well in my book.

If you spec something with risks, at least mark the critical parts clearly with "point away from foot".

A better standard IMHO would have suggested the API for the decode functions, making it clear that the algorithm used should be whiteli

I don't think the spec meant to read that you must allow the client to be able to forge tokens by accepting tokens issued by it without an algo or signature.

If you issue tokens with none, then you will have to accept them when clients send them back. This is obviously a very bad idea, but that's all th spec says. If the issuer chooses to be insecure, that is a valid choice.

If you issue tokens with a specific algo, and clients send them back with a different or none header, you know they have been forged.

The spec allows issuers to decide whether to use none, it doesn't say you must trust none tokens if you know you didn't issue them.

And the spec doesn't spell it out, and initial libraries implementations thus forgot to include things like "let the user specify which algos to accept". And if common libraries provide simple APIs, users expect that these APIs still provide good security.

A standard promoted as "the standard for secure tokens" should not aim for "You can use the pieces to build a correctly behaving system" or "the spec allows secure implementations", it should aim for "if you use this and follow some spelled-out basic rules you get fool-proof secure tokens" and make wrong usage as hard has possible.

> Why would an issuer ever let a client decide what algo to use?

Right, so, why is this in the spec?

The spec doesn't govern what applications can and cannot accept, it governs what contents are valid in tokens. 'None' is valid, that means my parser library will accept it, it doesn't mean my application must accept the token as valid.

Example: The fact that my service has an http stack which must parse a cookie header doesn't mean my app must accept its contents as valid. There's a lot of confusion on this thread about which components should/must do what things.

I guess I'm missing something here because it seems like the spec includes an ability that everyone here is saying nobody should ever use. Seems useless, by definition!

Reply on news.ycombinator.com