4 ms·

I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such s

by akfish 10y ago

I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks". But when is the last time we see any technology successfully prevented people from being silly?

ponytech 10y ago
I agree. I've read the whole article and still wonder why I should stop using JWT.
- slau 10y ago
  You shouldn't. Simply check that the hash algorithm specified by the client is the one you used when issuing the token. In a side project, I simply hard code the algorithm [1]. [1]: https://github.com/teotwaki/grace-calendar/blob/develop/app/helpers/jwt.rb https://github.com/teotwaki/grace-calendar/blob/develop/app/... Edit: DYAC.
RegEx 10y ago
https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228
nallerooth 10y ago
+1. I read the article and ended up with a TLDR where I expected some explanation and facts. It's a good thing that cookies have never been used in a bad manner. /sarcasm
sgift 10y ago
> But when is the last time we see any technology successfully prevented people from being silly? You can never stop someone sufficiently motivated to shoot himself in the foot from doing it. But you can make it harder for those who would do it be accident by providing more safety features - in case of security this is usually seen as a good idea (safe defaults etc.)
revelation 10y ago
But this is the biggest thing with any security-sensitive code or practice! Do not give people options, do not allow algorithmic flexibility, do not have fallbacks, do not have backward compatibility, do not allow "testing" or "insecure" options, do not have complex state machine behavior. All of these things are exactly what JWT or other "design by commission" standards like SSL suffer from and they have predictably lead to ongoing, at times unfixable security problems.

by akfish 10y ago

ponytech 10y ago

I agree. I've read the whole article and still wonder why I should stop using JWT.

slau 10y ago
You shouldn't. Simply check that the hash algorithm specified by the client is the one you used when issuing the token. In a side project, I simply hard code the algorithm [1]. [1]: https://github.com/teotwaki/grace-calendar/blob/develop/app/helpers/jwt.rb https://github.com/teotwaki/grace-calendar/blob/develop/app/... Edit: DYAC.

RegEx 10y ago

https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228

nallerooth 10y ago

+1. I read the article and ended up with a TLDR where I expected some explanation and facts. It's a good thing that cookies have never been used in a bad manner. /sarcasm

sgift 10y ago

> But when is the last time we see any technology successfully prevented people from being silly? You can never stop someone sufficiently motivated to shoot himself in the foot from doing it. But you can make it harder for those who would do it be accident by providing more safety features - in case of security this is usually seen as a good idea (safe defaults etc.)

revelation 10y ago

But this is the biggest thing with any security-sensitive code or practice! Do not give people options, do not allow algorithmic flexibility, do not have fallbacks, do not have backward compatibility, do not allow "testing" or "insecure" options, do not have complex state machine behavior. All of these things are exactly what JWT or other "design by commission" standards like SSL suffer from and they have predictably lead to ongoing, at times unfixable security problems.