5 ms·

Critical Vulnerabilities in JSON Web Token Libraries

59 points by mirceasoaica 11y ago

verroq 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      This was predicted http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-h... 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
  - billyhoffman 11y ago
    "I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities." This statement applies to roughly half of all security issues I have ever seen. I'm not making a joke or being flippant, and it reenforces what you need to consider when designing specs or APIs. Specs have surface area just like code does, and decreasing it often has positive outcomes for security.
taspeotis 11y ago
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 11y ago
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 11y ago
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 11y ago
  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 11y ago
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
landr0id 11y ago
It's worth noting that this article is from March.

59 points by mirceasoaica 11y ago

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 11y ago
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 11y ago
  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 11y ago
    This was predicted http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-h... 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
- billyhoffman 11y ago
  "I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities." This statement applies to roughly half of all security issues I have ever seen. I'm not making a joke or being flippant, and it reenforces what you need to consider when designing specs or APIs. Specs have surface area just like code does, and decreasing it often has positive outcomes for security.

taspeotis 11y ago

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 11y ago

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 11y ago

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 11y ago
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 11y ago

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

landr0id 11y ago

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