
Critical Vulnerabilities in JSON Web Token Libraries - mirceasoaica
https://www.timmclean.net/2015/03/31/jwt-algorithm-confusion.html
======
taspeotis
[https://news.ycombinator.com/item?id=9301054](https://news.ycombinator.com/item?id=9301054)

    
    
        Critical Vulnerabilities in JSON Web Token Libraries (auth0.com)
        147 points by pr0zac 58 days ago | cached | share | flag | 52 comments

------
tracker1
This is one instance where a naive approach may be better than a library...
the two times I've written/used JWT one time I used JWE (encrypted tokens)
with a private key... the other, I only supported public/private signing (no
HS256).

In practice, I tend to treat specifications as guidelines, more than absolute.
I wrote a simple SCORM implementation for an eLearning software that was
mainly for testing content being developed. This became the LMS for a _VERY_
large aerospace company for about 9 years, not to mention evolving and being
included as a base for several products since (over the past 12-13 years). I
didn't implement the entire spec, only what was most needed for my own use. It
went over 11 years before a missing piece of the spec was requested to be
added.

I guess the point is, when you have something that is as relatively easy to
implement as JWT, it makes sense to do it yourself, and only implement those
pieces that you need.

------
nly
IMHO the proposed API fix is also risky. I can see someone trying to be clever
and simply extracting "alg" from the header themselves, feeding it to
verify(), and then thinking "Jeez, why isn't this library smart enough to do
this for me?". Someone copying and pasting the snippet to Stack Overflow to do
just that would be inevitable. A better fix might be to make like /etc/shadow
and stick the algorithm type on to the front of the encoded secret key.

[Rant] Optionally use a statically typed language that supports overloading of
the original, nice simple, function instead of doing crypto on malleable data
formats in dynamically typed languages and expecting good results... if you go
to the JWT homepage[0] you'll see all the statically-typed languages are
unaffected by this vulnerability. Coincidence?

[0] [http://jwt.io/](http://jwt.io/)

~~~
tracker1
that's only half the suggested fix, the other half is to remove alg from the
header altogether... In practice, I've always ignored the alg header, and just
used the expected alg for my implementations.

------
SFjulie1
having worked with JWT token in places where it is used for monetary
transactions, I have been witnessing a creepy discrepancy between the required
level of knowledge to use them and the actual level of developers.

In one place, I was sacked for saying too loud that JWT are base64URL encoded
and not base64 encoded.

The JWT token being passed in get, it made the auth system fail 40% of the
time. And nobody understood the bug...

I sent the bug report internally to the security department, and they saw
nothing wrong.

I discussed with a lot of other coders, they saw nothing wrong.

My experience is JWT token are too complex to use.

An authenticated session HAS to be statefull, the web is stateless. That's the
point.

PS it looks a lot like a logjam attack

------
verroq
Issues like this aside, why couldn't they just design it using AES-GCM or
whatever authenticated encryption scheme instead of AES + MAC?

There is literally no reason to use encrypt + MAC when there are authenticated
encryption schemes available.

~~~
tracker1
I think the original intent of the spec was to allow some flexibility... in
practice supporting this flexibility lead to some vulnerabilities.

In this case, when you're expecting tokens using public/private pairs for
signing tokens and a client library also supports a different signing method,
you can forge a token targetting a specific client.

The purpose of having a signature method was to have a _fast_ system in place
for being able to verify a token per request... fully encrypted tokens have
slightly more overhead when there will be a lot of small requests... though
you can also use an in-memory, or simething like redis to have a cache of pre-
hashed tokens on the same system, which would reduce at least some overhead
for the validation.

As I mentioned in my own post, JWT is easy enough to implement an expected
methodology, when you are only supporting a single authority, that I hadn't
even considered the problem mentioned in the article, I'd actually ignored the
header part for my own use.

~~~
rockdoe
_I think the original intent of the spec was to allow some flexibility... in
practice supporting this flexibility lead to some vulnerabilities._

I think less than a week ago (weakdh) tptacek was mentioning on twitter that
security schemes should be versioned but not extensible exactly due to these
kind of errors.

~~~
SFjulie1
This was predicted [http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-
to-h...](http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/)

Oauth 2.0 is so much of a flexible framework it almost boils down to "roll
your own crypto with very complex tools and a lot of moving parts"

I am gonna watch the world burn safely eating my popcorn with my old fashions
AAA system (radius, LDAP, ssh..) expecting more vulnerabilities to be
uncovered and waiting for employers and architects to require my now valuable
knowledge.

Mouhahahahahahha

------
landr0id
It's worth noting that this article is from March.

