10 ms·

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 wit

by lxe 9y ago

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?

treve 9y ago
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.
- jopsen 9y ago
  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.
level 9y ago
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.
WorldMaker 9y ago
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.
JepZ 9y ago
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.
duskwuff 9y ago
> 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.
- lxe 9y ago
  But my code can just ignore the alg passed by the user and use whatever one I want to use.
  - lvh 9y ago
    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".

by lxe 9y ago

treve 9y ago

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.

jopsen 9y ago
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.

level 9y ago

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.

WorldMaker 9y ago

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.

JepZ 9y ago

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.

duskwuff 9y ago

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

lxe 9y ago
But my code can just ignore the alg passed by the user and use whatever one I want to use.
- lvh 9y ago
  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".