8 ms·

The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... he

by asanso 10y ago

The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... here FWIW. Personally I would not be so drastic. JOSE per se is not too bad (at least the idea is cool). Some crypto choices though have been really arguable...

tptacek 10y ago
That post is great work. Thanks again. But I think you're wrong about JWT. The problem with JWT/JOSE is that it's too complicated for what it does. It's a meta-standard capturing basically all of cryptography which, as you've ably observed (along with Matthew Green), was not written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of joinery. Good modern crypto constructions don't do complicated negotiation or algorithm selection. Look at Trevor Perrin's Noise protocol, which is the transport for Signal. Noise is instantiated statically with specific algorithms. If you're talking to a Chapoly Noise implementation, you cannot with a header convince it to switch to AES-GCM, let alone "alg:none". The ability to negotiate different ciphers dynamically is an own-goal. The ability to negotiate to no crypto, or (almost worse) to inferior crypto, is disqualifying. A good security protocol has good defaults. But JWT doesn't even get non-replayability right; it's implicit, and there's more than one way to do it. Application data is mixed with metadata (any attribute not in the JOSE header is in the same namespace as the application's data). Anything that can possibly go wrong, JWT wants to make sure will go wrong. It's 2017 and they still managed to drag all of X.509 into the thing, and they indirect through URLs. Some day some serverside library will implement JWK URL indirection, and we'll have managed to reconstitute an old inexplicably bad XML attack. For that matter, something crypto people understand that I don't think the JWT people do: public key crypto isn't better than symmetric key crypto. It's certainly not a good default: if you don't absolutely need public key constructions, you shouldn't use them. They're multiplicatively more complex and dangerous than symmetric key constructions. But just in this thread someone pointed out a library --- auth0's --- that apparently defaults to public key JWT. That's because JWT practically begs you to find an excuse to use public key crypto. These words occur in a JWT tutorial (I think, but am not sure, it's auth0's): "For this reason encrypted JWTs are sometimes nested: an encrypted JWT serves as the container for a signed JWT. This way you get the benefits of both." There are implementations that default to compressed. There's a reason crypto people table flip instead of writing detailed critiques of this protocol. It's a bad protocol. You look at this and think, for what? To avoid the effort of encrypting a JSON blob with libsodium and base64ing the output? Burn it with fire.
- asanso 10y ago
  I agree on all the accounts on what you said. I am probably biased by the fact I like JSON over XML. Probably JOSE just took the wrong path and could have been designed way better than it is...
- lclarkmichalek 10y ago
  What should I use instead? I pass around JWTs attached to HTTP requests that represent an authenticated user, and contain things such as a user's email, groups, scopes etc. I've tried to keep it simple (RSA, SHA256, nothing interesting), and use the subset of JWT that seems sane (basically the bits I see Google using in their JWT based OAuth flow) I used JWTs because 1. I like the statelessness of JWTs (though I've learnt that there are many trade offs related to this) 2. OAuth uses JWTs, Google uses OAuth, and Google usually know what they're doing 3. I can attach custom claims 4. I don't know of any alternatives, other than x509, which I have less confidence on me being able to validate correctly than JWTs. What would you suggest? An opaque token which I then look up against a central database/api?
  - tptacek 10y ago
    You're in luck! As I pointed out in the comment you replied to, JWT includes X.509.
  - zeveb 10y ago
    SPKI (RFCs 2692 & 2693) offers a well-developed, well-thought-out framework which meets all your needs: SPKI certificates can contain state, and thus support server statelessness; SPKI certificates can be used as OAuth tokens; SPKI certificates support custom claims (and in fact go so far as to define a well-formed claim calculus which can be implemented easily, and which supports just about anything one would wish to do); and SPKI certificates are far, far simpler than X.509. Take a look: https://tools.ietf.org/html/rfc2692 https://tools.ietf.org/html/rfc2692 & https://tools.ietf.org/html/rfc2693 https://tools.ietf.org/html/rfc2693
- davewritescode 10y ago
  JWT begs you to use public key because it makes sense for a lot of the use cases that people implement using JWT specifically having a single token issuer while having distributed token validation. Using a public key algorithms makes also it easier to implement a sane key rollover strategy. I suspect this is the reason that Auth0 pushes their customers to validate tokens with public keys published on their JWKS endpoints. As for X.509, I agree it kind of sucks but what are the alternatives?

by asanso 10y ago

tptacek 10y ago

That post is great work. Thanks again. But I think you're wrong about JWT. The problem with JWT/JOSE is that it's too complicated for what it does. It's a meta-standard capturing basically all of cryptography which, as you've ably observed (along with Matthew Green), was not written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of joinery. Good modern crypto constructions don't do complicated negotiation or algorithm selection. Look at Trevor Perrin's Noise protocol, which is the transport for Signal. Noise is instantiated statically with specific algorithms. If you're talking to a Chapoly Noise implementation, you cannot with a header convince it to switch to AES-GCM, let alone "alg:none". The ability to negotiate different ciphers dynamically is an own-goal. The ability to negotiate to no crypto, or (almost worse) to inferior crypto, is disqualifying. A good security protocol has good defaults. But JWT doesn't even get non-replayability right; it's implicit, and there's more than one way to do it. Application data is mixed with metadata (any attribute not in the JOSE header is in the same namespace as the application's data). Anything that can possibly go wrong, JWT wants to make sure will go wrong. It's 2017 and they still managed to drag all of X.509 into the thing, and they indirect through URLs. Some day some serverside library will implement JWK URL indirection, and we'll have managed to reconstitute an old inexplicably bad XML attack. For that matter, something crypto people understand that I don't think the JWT people do: public key crypto isn't better than symmetric key crypto. It's certainly not a good default: if you don't absolutely need public key constructions, you shouldn't use them. They're multiplicatively more complex and dangerous than symmetric key constructions. But just in this thread someone pointed out a library --- auth0's --- that apparently defaults to public key JWT. That's because JWT practically begs you to find an excuse to use public key crypto. These words occur in a JWT tutorial (I think, but am not sure, it's auth0's): "For this reason encrypted JWTs are sometimes nested: an encrypted JWT serves as the container for a signed JWT. This way you get the benefits of both." There are implementations that default to compressed. There's a reason crypto people table flip instead of writing detailed critiques of this protocol. It's a bad protocol. You look at this and think, for what? To avoid the effort of encrypting a JSON blob with libsodium and base64ing the output? Burn it with fire.

asanso 10y ago
I agree on all the accounts on what you said. I am probably biased by the fact I like JSON over XML. Probably JOSE just took the wrong path and could have been designed way better than it is...
lclarkmichalek 10y ago
What should I use instead? I pass around JWTs attached to HTTP requests that represent an authenticated user, and contain things such as a user's email, groups, scopes etc. I've tried to keep it simple (RSA, SHA256, nothing interesting), and use the subset of JWT that seems sane (basically the bits I see Google using in their JWT based OAuth flow) I used JWTs because 1. I like the statelessness of JWTs (though I've learnt that there are many trade offs related to this) 2. OAuth uses JWTs, Google uses OAuth, and Google usually know what they're doing 3. I can attach custom claims 4. I don't know of any alternatives, other than x509, which I have less confidence on me being able to validate correctly than JWTs. What would you suggest? An opaque token which I then look up against a central database/api?
- tptacek 10y ago
  You're in luck! As I pointed out in the comment you replied to, JWT includes X.509.
- zeveb 10y ago
  SPKI (RFCs 2692 & 2693) offers a well-developed, well-thought-out framework which meets all your needs: SPKI certificates can contain state, and thus support server statelessness; SPKI certificates can be used as OAuth tokens; SPKI certificates support custom claims (and in fact go so far as to define a well-formed claim calculus which can be implemented easily, and which supports just about anything one would wish to do); and SPKI certificates are far, far simpler than X.509. Take a look: https://tools.ietf.org/html/rfc2692 https://tools.ietf.org/html/rfc2692 & https://tools.ietf.org/html/rfc2693 https://tools.ietf.org/html/rfc2693
davewritescode 10y ago
JWT begs you to use public key because it makes sense for a lot of the use cases that people implement using JWT specifically having a single token issuer while having distributed token validation. Using a public key algorithms makes also it easier to implement a sane key rollover strategy. I suspect this is the reason that Auth0 pushes their customers to validate tokens with public keys published on their JWKS endpoints. As for X.509, I agree it kind of sucks but what are the alternatives?