3 ms·

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

detaro 10y ago
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 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
- fcvarela 10y ago
  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.
  - detaro 10y ago
    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.

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

fcvarela 10y ago
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.
- detaro 10y ago
  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.