4 ms·

No they don't. JWTs sign the whole token.

by kevincox 3y ago

tptacek 3y ago
They're also notoriously fragile!
- DaiPlusPlus 3y ago
  Can you be more specific? a JWT's structure is really simple and easier to process compared to what came before (SAML, etc). I accept there's fragility in the wider distributed-authX/federation ecosystem (e.g. browser cookie policies breaking OIDC), but that's not inherent in JWT.
  - tptacek 3y ago
    https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/
    - DaiPlusPlus 3y ago
      Nothing in that article mentions any kind of "fragility" in JWT's design - and the issues it documents (e.g. consumers overrwriting the signature portion) concern only extremely non-compliant (i.e. dodgy) JWT scenarios - which sounds like someone applying a bodge because they were forced to implement JWT because it was thrust onto them, usually because JWT is already so popular already - so it's nothing inherent in JWT specifically, but any kind of distributed, non-opaque and structured authX/id-token would suffer from the exact same problems - though I appreciate the textual-basis of JSON and JWT lower the barrier-to-entry-for-bodging compared to binary formats like ASN.1 (though I speculate that if we had to use a binary format today I think things would be a lot worse overall, due to second-order effects of using a binary format, e.g. relating to higher barriers-of-entry).
      - tptacek 3y ago
        No, none of that is true. Follow the links, too. Really, the whole article is about how to do better than JWT in an auth token format. It's always interesting to come across people who are surprised by things like JWT being considered a poor format. The only reason you don't see this said all the time in 2023 is that it was settled years ago. Cryptography engineers hate JWT.
        coldacid 3y ago
        >The only reason you don't see this said all the time in 2023 is that it was settled years ago. Was it? If it was settled, we wouldn't keep seeing these kinds of debates. >Cryptography engineers hate JWT. Appeal to authority. I'm sure that they hate plenty of other things too, doesn't make their opinions or emotions automatically correct.
        tptacek 3y ago
        It is indeed an appeal to authority. And, if you read the comment again, you'll see that you're agreeing with me: hearing that JWT is bad surprised the previous commenter precisely because we've stopped having meaningful discussions about whether JWT is good; it isn't, the case is closed, there's not much more to talk about.
robertlagrant 3y ago
They sign the header and payload. The third section is the signature itself.
- g_p 3y ago
  And (unless you manually fix your verification approach) they trust the (unverified at that time) header to declare the signature method used... Which at one point many implementations would accept as "null". So you could take a signed JWT, strip the signature, and set the header to indicate to the verified a null signature was verified.
  - kevincox 3y ago
    Yes. This is definitely one of the weaknesses of JWT. It is prudent to whitelist the allowed headers. And the fact that any implementations accepted `null` as an algorithm is awful.
  - robertlagrant 3y ago
    This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.
    - growse 3y ago
      > This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format. What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...
      - maccard 3y ago
        There's a difference between trust and blindly trusting.
      - tharkun__ 3y ago
        The point of input in any case is that you are going to validate it and then process it. Any input that isn't validated should not be trusted, even in the most benign scenarios and triply so in security relevant contexts. Someone specifies the `null` algorithm? Reject the token outright, someone's trying fudge things. Someone specifies the `blahwhatever` algorithm that you actually trust yourself. Sure, try that algorithm, if results come back valid, all is good. Results come back bad? Reject the input without trying any of the other 19 algorithms you support and trust on the input. As you can see here, the purpose of the field is to make it easy to validate the token without having to try all the algorithms that you might support. If you support 20 algorithms for something, you don't want to have to try all of them. But you do have to know which algorithms you trust. It's really not different from an SSL negotiation. You know which algorithms you accept/support, the other side knows what algorithms it accepts/supports. If you can't find one both of you support: tough luck!

No they don't. JWTs sign the whole token.

tptacek 3y ago

They're also notoriously fragile!

DaiPlusPlus 3y ago
Can you be more specific? a JWT's structure is really simple and easier to process compared to what came before (SAML, etc). I accept there's fragility in the wider distributed-authX/federation ecosystem (e.g. browser cookie policies breaking OIDC), but that's not inherent in JWT.
- tptacek 3y ago
  https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/
  - DaiPlusPlus 3y ago
    Nothing in that article mentions any kind of "fragility" in JWT's design - and the issues it documents (e.g. consumers overrwriting the signature portion) concern only extremely non-compliant (i.e. dodgy) JWT scenarios - which sounds like someone applying a bodge because they were forced to implement JWT because it was thrust onto them, usually because JWT is already so popular already - so it's nothing inherent in JWT specifically, but any kind of distributed, non-opaque and structured authX/id-token would suffer from the exact same problems - though I appreciate the textual-basis of JSON and JWT lower the barrier-to-entry-for-bodging compared to binary formats like ASN.1 (though I speculate that if we had to use a binary format today I think things would be a lot worse overall, due to second-order effects of using a binary format, e.g. relating to higher barriers-of-entry).
    - tptacek 3y ago
      No, none of that is true. Follow the links, too. Really, the whole article is about how to do better than JWT in an auth token format. It's always interesting to come across people who are surprised by things like JWT being considered a poor format. The only reason you don't see this said all the time in 2023 is that it was settled years ago. Cryptography engineers hate JWT.
      - coldacid 3y ago
        >The only reason you don't see this said all the time in 2023 is that it was settled years ago. Was it? If it was settled, we wouldn't keep seeing these kinds of debates. >Cryptography engineers hate JWT. Appeal to authority. I'm sure that they hate plenty of other things too, doesn't make their opinions or emotions automatically correct.
        tptacek 3y ago
        It is indeed an appeal to authority. And, if you read the comment again, you'll see that you're agreeing with me: hearing that JWT is bad surprised the previous commenter precisely because we've stopped having meaningful discussions about whether JWT is good; it isn't, the case is closed, there's not much more to talk about.

robertlagrant 3y ago

They sign the header and payload. The third section is the signature itself.

g_p 3y ago
And (unless you manually fix your verification approach) they trust the (unverified at that time) header to declare the signature method used... Which at one point many implementations would accept as "null". So you could take a signed JWT, strip the signature, and set the header to indicate to the verified a null signature was verified.
- kevincox 3y ago
  Yes. This is definitely one of the weaknesses of JWT. It is prudent to whitelist the allowed headers. And the fact that any implementations accepted `null` as an algorithm is awful.
- robertlagrant 3y ago
  This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.
  - growse 3y ago
    > This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format. What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...
    - maccard 3y ago
      There's a difference between trust and blindly trusting.
    - tharkun__ 3y ago
      The point of input in any case is that you are going to validate it and then process it. Any input that isn't validated should not be trusted, even in the most benign scenarios and triply so in security relevant contexts. Someone specifies the `null` algorithm? Reject the token outright, someone's trying fudge things. Someone specifies the `blahwhatever` algorithm that you actually trust yourself. Sure, try that algorithm, if results come back valid, all is good. Results come back bad? Reject the input without trying any of the other 19 algorithms you support and trust on the input. As you can see here, the purpose of the field is to make it easy to validate the token without having to try all the algorithms that you might support. If you support 20 algorithms for something, you don't want to have to try all of them. But you do have to know which algorithms you trust. It's really not different from an SSL negotiation. You know which algorithms you accept/support, the other side knows what algorithms it accepts/supports. If you can't find one both of you support: tough luck!