4 ms·

egberts1, can you please share your reasons for "DO NOT use JWT"? The citation on your blog only links to the wikipedia page https://en.wikipedia.org/wiki/JSON_

egberts1, can you please share your reasons for "DO NOT use JWT"? The citation on your blog only links to the wikipedia page https://en.wikipedia.org/wiki/JSON_Web_Token https://en.wikipedia.org/wiki/JSON_Web_Token rather than a resource describing any issues with JWTs specifically. ...I also have to wonder why no CORS. When properly managed (e.g. static-whitelisted allowed origins + allowed credentials from/to dedicated domains) and combined with other best practices around your web SSO framework of choice, it's fine for contexts such as SSO with no back-end sync.

jugg1es 6y ago
yea there is zero justification in your blog - just references to pages describing the technology. I would be interested to know what the rational is.
- egberts1 6y ago
  Yes. That is true what you’ve said. Sometime, with waves of web pages, coupled with the analytical thoughts of weakness in each leg of a protocol, I should have explicitly noted them. In this case, I was in a hurry to put it down. Better to document what I’ve noticed and find justification later. My bad.
  - egberts1 6y ago
    So, I’ve added more on CORS in earlier thread under this GP.
    - jugg1es 6y ago
      your rationale leaves something to be desired. I don't know if its really valid to consider something a dangerous tech just because it can be misused. Your computer can be very dangerous if misused - such as if you drop it out of a window on someone's head - that doesn't mean you shouldn't use a computer :)
      - egberts1 6y ago
        As one who develops IDS/IPS for 23 years, it isn’t a “dangerous” issue, per se. It’s a “muddle” issue that runs contravenous to that “be liberal in what you receive, and conservative in what you send.” Like “exec” is for JavaScript.
michaelchisari 6y ago
I can't speak for egberts1, but Thomas Ptacek(@tptacek) has written a lot on why JWTs should be avoided. Here's an HN search for his comments on JWTs: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=author%3Atptacek%20jwt&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... Here is one of his comments about JWT: In cryptography, we have a concept of "misuse resistance". https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223)
- toomuchtodo 6y ago
  The comment you link to is gold. Thank you.
egberts1 6y ago
CORS isn’t bad practice. It is supported on all major browsers, and more and more APIs are supporting it. In fact, if you have a public resource that is not behind a firewall, it is safe to put the Access-Control-Allow-Origin: * header on the resource. But there is some confusion over the role of CORS on a server. CORS should only dictate the cross-origin policy for a particular resource. In other words, the CORS headers are only meant to indicate whether requests from different origins are allowed. I think the confusion comes in because servers sometimes use CORS to dictate security policy as well. CORS is not security. If servers have resources that need to be protected from certain users, it is not safe to rely solely on the Origin header to enforce this. Your server needs some other mechanism for security (such as OAuth2 and CSRF protection). In short, CORS is not about security of the server. And it is not even considered a whole security for end-users but about the preventing your server from misusing your clients’ “WebOS” resources by your 3rd party affiliates (advertisers), and pretty much nothing else.

jugg1es 6y ago

yea there is zero justification in your blog - just references to pages describing the technology. I would be interested to know what the rational is.

egberts1 6y ago
Yes. That is true what you’ve said. Sometime, with waves of web pages, coupled with the analytical thoughts of weakness in each leg of a protocol, I should have explicitly noted them. In this case, I was in a hurry to put it down. Better to document what I’ve noticed and find justification later. My bad.
- egberts1 6y ago
  So, I’ve added more on CORS in earlier thread under this GP.
  - jugg1es 6y ago
    your rationale leaves something to be desired. I don't know if its really valid to consider something a dangerous tech just because it can be misused. Your computer can be very dangerous if misused - such as if you drop it out of a window on someone's head - that doesn't mean you shouldn't use a computer :)
    - egberts1 6y ago
      As one who develops IDS/IPS for 23 years, it isn’t a “dangerous” issue, per se. It’s a “muddle” issue that runs contravenous to that “be liberal in what you receive, and conservative in what you send.” Like “exec” is for JavaScript.

michaelchisari 6y ago

I can't speak for egberts1, but Thomas Ptacek(@tptacek) has written a lot on why JWTs should be avoided. Here's an HN search for his comments on JWTs: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=author%3Atptacek%20jwt&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... Here is one of his comments about JWT: In cryptography, we have a concept of "misuse resistance". https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223)

toomuchtodo 6y ago
The comment you link to is gold. Thank you.

egberts1 6y ago

CORS isn’t bad practice. It is supported on all major browsers, and more and more APIs are supporting it. In fact, if you have a public resource that is not behind a firewall, it is safe to put the Access-Control-Allow-Origin: * header on the resource. But there is some confusion over the role of CORS on a server. CORS should only dictate the cross-origin policy for a particular resource. In other words, the CORS headers are only meant to indicate whether requests from different origins are allowed. I think the confusion comes in because servers sometimes use CORS to dictate security policy as well. CORS is not security. If servers have resources that need to be protected from certain users, it is not safe to rely solely on the Origin header to enforce this. Your server needs some other mechanism for security (such as OAuth2 and CSRF protection). In short, CORS is not about security of the server. And it is not even considered a whole security for end-users but about the preventing your server from misusing your clients’ “WebOS” resources by your 3rd party affiliates (advertisers), and pretty much nothing else.