On 01/04/15 20:01, Tim McLean wrote:
Hello,I have been reviewing implementations of the JSON Web Token spec (draft-ietf-oauth-json-web-token), many of which are used in production systems, and have found that many of them allow an attacker to bypass the signature verification mechanism. Most libraries implement verification logic similar to the following: boolean verify(string token, string key): decode the header and extract the `alg` parameter decide based on `alg` how to verify the token signature return the result of that verification This is hugely problematic, as `alg` is an attacker-controlled parameter. In some libraries, specifying "alg":"none" will cause the verification to succeed and ignore the specified `key`. In other cases, I can bypass RSA/ECDSA verification by tricking the library into using the public key as an HMAC secret. I wrote up a full walk-through of these problems in this blog post: https://www.timmclean.net/2015/03/31/jwt-algorithm-confusion.html I would like to propose deprecating the `alg` field. Nearly every implementation that I've reviewed has trusted what algorithm was specified in the token. They should be basing their choice of algorithm on how the key was /intended/ to be used. Without an `alg` field inside the token, implementers would need to ask their API users to specify what algorithm was expected -- perfectly mitigating these vulnerabilities.
Our library requires the verifiers initialized with the expected algo, as opposed to supporting the provided algo property out of the box. It is an obvious thing to have IMHO. It is not right to portrait it as a weakness of the JWS spec...
I also agree that 'none' can be a useful feature, not only in a trusted channel but also as a way to use a generic JWE-JWS function where JWE encryption only is important
Sergey
I should point out that this proposal does not limit cryptographic agility. The key ID field (`kid`) is adequate for this purpose. Since keys should only ever be used with one algorithm (to avoid unexpected cryptographic interactions), determining which key to use implicitly determines which algorithm to use (since each key should be tied to its intended algorithm). This means that JWT users can easily support multiple algorithms by supporting multiple keys, and transition between algorithms by transitioning between keys. Cheers, Tim McLean PS: My apologies if this message was not sent to the right place -- I am new to IETF procedures. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
