This sounds like a basic misunderstanding about the role of a "security
toolkit" vs. an end-to-end protocol that uses a toolkit (e.g., SAML or
openID Connect).
For example, all of the crypto primitives available in java (jca/jce)
could also be "misused" in these ways, so I am not sure this analysis is
very helpful.
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
