Hacker News Reader

Comment by robertlagrant | Hacker News Reader

I don't see why that's fragile? E.g. JWTs work this way.

JWTs are the poster child of fragile signature design. If something is like JWTs, you should reconsider. Many implementations allowed JWTs with a null signature scheme, completely bypassing any security!

The assertion was that allowing signatures for sub-parts of the information is extremely fragile. Your example of null signatures being allowed would equally affect sub-part signing and whole document signing, so doesn't really show that sub-part signing is a problem.

It’s also difficult to actually get people on board with the idea of supplying a user-specific signing key instead of relying on a global one.

Instead they’ll end up persisted in a data store, making them stateful, because there’s no reliable way to invalidate such a token simply by rotating the signing key. Or using a cookie-backed session.

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

They're also notoriously fragile!

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.

https://fly.io/blog/api-tokens-a-tedious-survey/

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).

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.

>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.

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.

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

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.

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.

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.

> 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...

There's a difference between trust and blindly trusting.

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!

The existence of algorithm confusion attacks shows that it's not nearly as simple as just saying "Reject 'null'". It's a complete minefield, and the fact that the JWT scheme punts that complexity and "make sure you hold it correctly!" onto the application is bad.

Had the algorithm been standardised to a single value out of band (ie. in the spec), that would have squashed a whole load of vulnerabilities.

What whole load is that? The only one I know of is the (silly) existence of the null algorithm.

For example: simply take a valid identity's public key, and use it as the secret to forge a token with alg=hs256. A service receiving this token will use its copy of the public key (by key id) to verify the signature, but because it's being told that it's an HMAC-signed token, will construct an HMAC.

Of course this HMAC will verify correctly because both you (the attacker) and the server hold the same public key used. And now the server thinks its a legitimate JWT because the signature is valid.

Mixing symmetric and asymmetric cryptography types in the same message scheme is just one of the many ways in which JWT is a bad idea.

I really don't think this is an intrinsic problem at all.

I've written JWT-parsing code and it looked for a local public key if it got an RS-algorithm and a local secret if it got an HMAC algorithm. It would be an insane implementation to treat either of them as the other.

You should be validating all protected headers, in much the same way as border patrol should reject a crayon drawing of a passport.

JWS (and JWT) standardized interoperable parameters and what they mean, but applications are supposed to standardize how they are used.

An integrity protected message used as part of a transaction, one used to represent user state, and one used for document archival are going to have dramatically different requirements for verification metadata.

Similarly, a signed message issued by a single site vs one meant for use across a federation will have different requirements.

This is the #1 misconception of JWS/JWT which has led to people mislabeling it as insecure. They are only using the half that defines what fields mean, and ignoring application-specific instructions on if they are supposed to accept and how they are supposed to process those fields.

The header can be trusted, but "null" shouldn't be a permitted algorithm.

That is effectively "the full token". It is pretty difficult to sign the signature.

It is, but that is the topic at hand:

> Signatures should really just be applied to whole files or data structures, everything else should be considered dangerous

Reply on news.ycombinator.com