nice stuff Tim
said that,
On Apr 1, 2015, at 9:01 PM, Tim McLean
<[email protected]<mailto:[email protected]>> 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.
this is true. But is the string key also controlled my an attacker? In my
experience not…
regards
antonio
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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
