5 ms·

> Only if you completely bungle the implementation on the server-side. I call this "blaming the user for the designer's error-prone cryptographic designs". Th

> Only if you completely bungle the implementation on the server-side. I call this "blaming the user for the designer's error-prone cryptographic designs". The problem with JOSE (the superset of specifications that includes JWT) isn't libraries written by careless developers, the problem with JOSE is the standard itself. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... If in doubt, ask a cryptographer. The problems, for people who don't want to read articles from comment links, are: - JSON Web Signing - alg headers - "This Header Parameter MUST be present and MUST be understood and processed by implementations." - JSON Web Encryption - RSA with PKCS1v1.5 padding (power word: Bleichenbacher 1998) - ECDH over NIST curves (and, in practice, invalid-curve attacks) - AES-GCM included in a list of asymmetric algorithm choices, for added confusion - AES-GCM for shared-key encryption, without guidance over nonces or key rotation A better solution from JOSE would only give developers two options: - Version (v1, v2, v3, etc. which hard-coded the algorithm choices) - Operation - enc -> crypto_secretbox() - auth -> crypto_auth() - pub-enc -> crypto_box_seal() - pub-sign -> crypto_sign_detached()

rattray 9y ago
So, as suggested above, come up with a standard that encodes that subset – "Iron-JWT" or what have you. Much easier for adoption to use a "better version" of the widely-used tool you're already using than some newfangled thing that a guy on HN said was more secure.
- CiPHPerCoder 9y ago
  I've previously made my proposal to the JOSE IETF mailing list. The participants just held their nose up to it. https://www.ietf.org/mail-archive/web/jose/current/msg05621.html https://www.ietf.org/mail-archive/web/jose/current/msg05621.... https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03 https://gist.github.com/paragonie-scott/c88290347c2589b0cd38... When I'm not dealing with client work, I'll write a replacement for JOSE that has the properties I outlined above. Until I find the free time for this, things that increase my income take precedence.
  - yuhong 9y ago
    Notice that they did not include JWT in this!
    - CiPHPerCoder 9y ago
      JWT uses JWS, JWE, or both. Any criticism that targets JWE and JWS is necessarily relevant to JWT. The problems with JWT being addressed are in the domain of cryptography designs, so it's natural to criticize the cryptography components. The other problem with JWT is how people use it: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...
      - deleted 9y ago
        [deleted]
      - yuhong 9y ago
        The point however is that JWS/JWE is not as flawed as JWT is.
        CiPHPerCoder 9y ago
        Yes it is. Most of the problems people point to with JWT exist in JWS or JWE.
deathanatos 9y ago
Specifying "v1" "v2" or "v3" is not materially different than specifying the exact algorithm by name, which is what JWT does. You (and the linked article) are selectively quoting the JWS specification too, to imply that the server needs to always handle a token presented to it, regardless of the specified algorithm; the article is misleading the reader by doing so. The RFC also states, > Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid. As for the section about "MUST be understood and processed": the standard is simply saying that implementors must use the "alg" field. You can't ignore it. Extending that to "must process anything the client sends" results in nonsense. The suggestion to "use NaCl" ignores the entirety of JWT claims, and foists implementation of that functionality onto every single consumer that needs them. (And you hope that they recognize that they need them.) Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. While some JWT implementations had bugs in the past, these same bugs could easily be present in the custom implementations of your proposal, of which there would be many.
- CiPHPerCoder 9y ago
  From https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 > * Flaws in crypto protocols aren't exclusive to, but tend to occur mostly in, the joinery of the protocol. So crypto protocol designers are moving away from algorithm and "cipher suite" negotiation towards other mechanisms. Trevor Perrin's Noise framework is a great example: rather than negotiating, it defines a family of protocols and applications can adopt one or the other without committing themselves to supporting different ones dynamically. Not only does JWT do a form of negotiation, but it actually allows implementations to negotiate NO cryptography. That's a disqualifying own-goal. My proposal replaces the joinery with "select a version". You don't get to mix-and-match primitives. You won't fall into the trap of Reasoning By Lego. > Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. I'm not throwing my hands up and saying "fend for yourselves". I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time, as keeping a roof over my family's head takes precedence over doing a lot of thankless unpaid work.

rattray 9y ago

So, as suggested above, come up with a standard that encodes that subset – "Iron-JWT" or what have you. Much easier for adoption to use a "better version" of the widely-used tool you're already using than some newfangled thing that a guy on HN said was more secure.

CiPHPerCoder 9y ago
I've previously made my proposal to the JOSE IETF mailing list. The participants just held their nose up to it. https://www.ietf.org/mail-archive/web/jose/current/msg05621.html https://www.ietf.org/mail-archive/web/jose/current/msg05621.... https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03 https://gist.github.com/paragonie-scott/c88290347c2589b0cd38... When I'm not dealing with client work, I'll write a replacement for JOSE that has the properties I outlined above. Until I find the free time for this, things that increase my income take precedence.
- yuhong 9y ago
  Notice that they did not include JWT in this!
  - CiPHPerCoder 9y ago
    JWT uses JWS, JWE, or both. Any criticism that targets JWE and JWS is necessarily relevant to JWT. The problems with JWT being addressed are in the domain of cryptography designs, so it's natural to criticize the cryptography components. The other problem with JWT is how people use it: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...
    - deleted 9y ago
      [deleted]
    - yuhong 9y ago
      The point however is that JWS/JWE is not as flawed as JWT is.
      - CiPHPerCoder 9y ago
        Yes it is. Most of the problems people point to with JWT exist in JWS or JWE.

deathanatos 9y ago

Specifying "v1" "v2" or "v3" is not materially different than specifying the exact algorithm by name, which is what JWT does. You (and the linked article) are selectively quoting the JWS specification too, to imply that the server needs to always handle a token presented to it, regardless of the specified algorithm; the article is misleading the reader by doing so. The RFC also states, > Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid. As for the section about "MUST be understood and processed": the standard is simply saying that implementors must use the "alg" field. You can't ignore it. Extending that to "must process anything the client sends" results in nonsense. The suggestion to "use NaCl" ignores the entirety of JWT claims, and foists implementation of that functionality onto every single consumer that needs them. (And you hope that they recognize that they need them.) Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. While some JWT implementations had bugs in the past, these same bugs could easily be present in the custom implementations of your proposal, of which there would be many.

CiPHPerCoder 9y ago
From https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 > * Flaws in crypto protocols aren't exclusive to, but tend to occur mostly in, the joinery of the protocol. So crypto protocol designers are moving away from algorithm and "cipher suite" negotiation towards other mechanisms. Trevor Perrin's Noise framework is a great example: rather than negotiating, it defines a family of protocols and applications can adopt one or the other without committing themselves to supporting different ones dynamically. Not only does JWT do a form of negotiation, but it actually allows implementations to negotiate NO cryptography. That's a disqualifying own-goal. My proposal replaces the joinery with "select a version". You don't get to mix-and-match primitives. You won't fall into the trap of Reasoning By Lego. > Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. I'm not throwing my hands up and saying "fend for yourselves". I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time, as keeping a roof over my family's head takes precedence over doing a lot of thankless unpaid work.