Hacker News Reader

Comment by lxe | Hacker News Reader

I really don't get the whole "the spec supports choosing of algorithm, therefore the whole implementation is bad"

If my server-side application sends a JWT with a "good" algorithm, and disallows any other alg's, wouldn't that prevent attacks?

Why do we need a whole new implementation?

View on HN

The problem is that it's not idiot-proof. If someone doesn't understand why the algorithm is important, they might choose none. It's easy to say "they shouldn't be using JWTs if they don't know how to use them", but everyone starts somewhere, and everyone puts stupid bugs into production.

JWT is safe, as long as it's setup correctly, but safe-by-default is a better option.

That being said, I'm not going to swap out my JWTs with PASTs. I know what algorithm I'm using, why I'm using it, it is safe, and I'm verifying them properly.

I am totally with you. For me JWT is the idea to store encrypted values client-side which you can use to authenticate the client and is different to the old way of just storing a random 'dumb' session id with the linked values somewhere on the server.

So yes, I appreciate secure and easy-to-use implementations of that idea, but always going for how insecure JWTs are, just because there are easy ways to do it wrong, is like telling everybody that password logins are bad because some people implemented them in flash.

> Why do we need a whole new implementation?

I think the problem which many people have with JWT is that is not strict enough and does not define certain things. PAST uses the same idea, but does not allow that wide variety of different algorithms we could use with JWT. In my eyes it makes it easier to use, because you do not have to search for implementations with compatible and secure algorithms but just for implementations using the latest version of PAST.

> If my server-side application sends a JWT with a "good" algorithm, and disallows any other alg's, wouldn't that prevent attacks?

It does not. Unless you have specifically hardened your server to refuse to even try verifying tokens which use "bad" algorithms, a client can still present a key signed with one of those algorithms, and attempting to verify it may pose a risk.

But my code can just ignore the alg passed by the user and use whatever one I want to use.

If you're going to ignore compatibility anyway, you could also use good crypto. The JWT doesn't define what "Recommended" and "Recommended+" means but apparently RSA+PKCSv15 is Recommended+ so I guess it means "crypto known to be broken in the 90s".

I think one of the issues is a very practical one. When everything is called JWT, it's hard for users to figure out whether it's a secure or insecure implementation.

It's completely possible to do secure things with JWT, especially if you control every producer and consumer, but it's not guaranteed.

It's completely possible to do insecure things with PAST.

There is always going to be someone who hardcodes the root password into a public GitHub repo.

The problem with JWT is IMO largely that things became too easy, so people coded without thinking. I'm not sure that's easy to prevent. I don't blame the JWT spec for mistakes that are so obvious.

There's also the issue that the alg field is in an encoded section of the JWT payload and has to be base64-decoded and then JSON parsed. There have been buffer overrun and malicious JSON attacks on JWT.

PAST at least moves that to a clear text prefix in the vx.scheme pattern. Theoretically, that doesn't even stop it from having a v0.none or some other dumb algorithm such as JWT allows in a bad version suite, but it does at least mitigate against decryption attacks.

Reply on news.ycombinator.com