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