5 ms·

> Only if you completely bungle the implementation on the server-side. Which happens with regularity. This is exactly what led to the vulnerabilities mentione

> Only if you completely bungle the implementation on the server-side. Which happens with regularity. This is exactly what led to the vulnerabilities mentioned in the article. This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? As it turns out, that's an extremely common mistake. It's easier to use a known-safe practice like parameterised queries than it is to rely on developers avoiding this pitfall each and every time they have to execute an SQL query. Likewise with this. We know that negotiating the algorithm is subject to mistakes, and it offers no benefits. So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation. There's a human aspect to security that's being missed here. Saying what boils down to "well developers shouldn't write insecure code" doesn't actually stop developers from writing insecure code. You can point the finger after the fact, but if you want to actually improve security, we need better standards than this.

Freak_NL 10y ago
> This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? No, you document how it should be done. Any major database layer using SQL provides parametrised SQL queries, and strongly suggests developers use that (usually in the quick start guide). You can still do your own concatenation, but aren't advised to. The JWT libraries that are up-to-date and well-documented don't recommend blindly trusting the algorithm set in the header either, they recommend safe approaches such as configuring your whitelist and letting any unlisted algorithms fail. For example: https://github.com/auth0/java-jwt#verify-a-token https://github.com/auth0/java-jwt#verify-a-token Only if you completely refuse to read even the basic 'getting started' documentation will you get to this kind of weird vulnerability. The issues with this part of the JWT standard have been addressed by the libraries, what remains is just a little bit of effort on the part of the developer — which may be expected from someone writing security critical code. That is, don't blame the hammer for the shoddy carpentry. > So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation. So write a concise pamphlet that can easily be shared with all of the JWT libraries in an issue/bug report. If there is a good argument for having to explicitly whitelist algorithms, they might welcome the suggestion. Some libraries already do this mind!
- kevinburke 10y ago
  I just documented how it should be done, in the article at the top of the page. The answer is "don't use JWT." Use specific tools for the thing you are actually trying to do, that have API's that are harder to mess up.
  - Minikloon 10y ago
    By that logic the answer is also "don't use SQL".
    - kevinburke 10y ago
      More like "Don't use SQL, if a thing adjacent to SQL exists that is better suited to a particular use case, doesn't have a history of poor implementations, and is harder for implementers and end users to screw up." In this case: - crypto_auth, or HMAC-SHA256 by itself, for authentication - crypto_secretbox for symmetric encryption - crypto_box or TLS for public key encryption
      - wolco 10y ago
        But what happens is that sql version becomes sqlite and it doesn't provided enough power or flexibility.
      - deathanatos 10y ago
        Good JWT libraries essentially have a "box" and "unbox" function; the work required by the client needed to go behind the library's back here is on the same level as that needed to behind crypto_box's. Further, crypto_box works on a lower level than JWT encode/decode functions typically do, and would leave many concerns that JWTs handle in the user's hands for them to handle, alone. Having the user write their own code to handle those concerns is a terrible idea.
        mmalone 10y ago
        I'm with you on this. I've never thought of JWTs as a session storage mechanism; rather, I've always thought of them as a simpler (JSON-based) alternative to technologies like X.509 attribute certificates and SAML assertions. If you're creating a ticket / verifiable claim, there are a bunch of security considerations that JWT at least lays the groundwork for, and that NaCl secretbox doesn't appear to offer. Curious what OP thinks about putting things like payload canonicalization, subject/issuer/audience specification, and expiration entirely in the user's hands. I suppose its up to implementors to do appropriate validation, but at least JWT simplifies the conversation a bit.
tracker1 10y ago
And that hasn't happened with similar authentication systems... I'd be surprised if there weren't a lot of broken OAuth/OpenAuth/OpenID systems with similar issues in the wild. Most of the issues I've seen with JWT I hadn't experienced because I hadn't thought to even allow such variety... in one case, the public key was cached from a fixed URL, and in others, shared key was forced in place. It's only when you leave things open, or use a poorly implemented library that you have issues. It's a really easy standard to understand, and frankly most of the library implementations suck, but it's really easy to roll your own, and lock it down to the single implementation details you use internally.

Freak_NL 10y ago

> This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? No, you document how it should be done. Any major database layer using SQL provides parametrised SQL queries, and strongly suggests developers use that (usually in the quick start guide). You can still do your own concatenation, but aren't advised to. The JWT libraries that are up-to-date and well-documented don't recommend blindly trusting the algorithm set in the header either, they recommend safe approaches such as configuring your whitelist and letting any unlisted algorithms fail. For example: https://github.com/auth0/java-jwt#verify-a-token https://github.com/auth0/java-jwt#verify-a-token Only if you completely refuse to read even the basic 'getting started' documentation will you get to this kind of weird vulnerability. The issues with this part of the JWT standard have been addressed by the libraries, what remains is just a little bit of effort on the part of the developer — which may be expected from someone writing security critical code. That is, don't blame the hammer for the shoddy carpentry. > So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation. So write a concise pamphlet that can easily be shared with all of the JWT libraries in an issue/bug report. If there is a good argument for having to explicitly whitelist algorithms, they might welcome the suggestion. Some libraries already do this mind!

kevinburke 10y ago
I just documented how it should be done, in the article at the top of the page. The answer is "don't use JWT." Use specific tools for the thing you are actually trying to do, that have API's that are harder to mess up.
- Minikloon 10y ago
  By that logic the answer is also "don't use SQL".
  - kevinburke 10y ago
    More like "Don't use SQL, if a thing adjacent to SQL exists that is better suited to a particular use case, doesn't have a history of poor implementations, and is harder for implementers and end users to screw up." In this case: - crypto_auth, or HMAC-SHA256 by itself, for authentication - crypto_secretbox for symmetric encryption - crypto_box or TLS for public key encryption
    - wolco 10y ago
      But what happens is that sql version becomes sqlite and it doesn't provided enough power or flexibility.
    - deathanatos 10y ago
      Good JWT libraries essentially have a "box" and "unbox" function; the work required by the client needed to go behind the library's back here is on the same level as that needed to behind crypto_box's. Further, crypto_box works on a lower level than JWT encode/decode functions typically do, and would leave many concerns that JWTs handle in the user's hands for them to handle, alone. Having the user write their own code to handle those concerns is a terrible idea.
      - mmalone 10y ago
        I'm with you on this. I've never thought of JWTs as a session storage mechanism; rather, I've always thought of them as a simpler (JSON-based) alternative to technologies like X.509 attribute certificates and SAML assertions. If you're creating a ticket / verifiable claim, there are a bunch of security considerations that JWT at least lays the groundwork for, and that NaCl secretbox doesn't appear to offer. Curious what OP thinks about putting things like payload canonicalization, subject/issuer/audience specification, and expiration entirely in the user's hands. I suppose its up to implementors to do appropriate validation, but at least JWT simplifies the conversation a bit.

tracker1 10y ago

And that hasn't happened with similar authentication systems... I'd be surprised if there weren't a lot of broken OAuth/OpenAuth/OpenID systems with similar issues in the wild. Most of the issues I've seen with JWT I hadn't experienced because I hadn't thought to even allow such variety... in one case, the public key was cached from a fixed URL, and in others, shared key was forced in place. It's only when you leave things open, or use a poorly implemented library that you have issues. It's a really easy standard to understand, and frankly most of the library implementations suck, but it's really easy to roll your own, and lock it down to the single implementation details you use internally.