5 ms·

There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling w

There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your own validation, unless you absolutely have to, which you don't, and even then only with lots and lots of review/audits." The wisdom with JWT should be the same, IMO.

kevinburke 8y ago
Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.
- andrewstuart2 8y ago
  I never said "all security software has flaws," since that has a substantially different meaning than my comment. While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid some of the potential downsides of pocket knives. That doesn't make pocket knives useless, it just means that you might need to be trained on safely using a pocket knife, whereas I'm totally comfortable handing a butter knife to my four-year-old. If you're going to be trusted with security, you're really going to need either a) a sharper knife, or b) to understand which knives you're okay handing to your coworkers, or c) to be able to train your coworkers on proper knife safety so they can also use the more flexible tools, but still safely.
  - kevinburke 8y ago
    Well the good news is I've written about this exact subject at length! I have seen JWT implementations at five or six different companies now, tokens have never been used for more than one use case. For each specific use case you'd actually want to use it with there is a better solution that doesn't involve JWT, like secretbox or HMAC-SHA256. https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/ https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/
    - CiPHPerCoder 8y ago
      You might be happy to see the PASETO spec, which (for v2) uses XChaCha20-Poly1305 for encryption, Ed25519 for signatures, separates the two logically, and doesn't allow for runtime ciphersuite negotiation. (v1 achieves a similar result with AES-CTR+HMAC-SHA384-EtM and RSASSA-PSS.) https://github.com/paragonie/paseto/tree/master/docs/01-Protocol-Versions https://github.com/paragonie/paseto/tree/master/docs/01-Prot... It's similar to the advice given above, but also caters to that itch that some project managers have to only implement industry standards (which PASETO is slowly becoming).
      - sierdolij 8y ago
        PASETO seems to signal quality: libsodium, simple spec, platform-agnostic in the freak'n name. I keep seeing the horrors and defects of JOSE/JWT, but then it keeps getting promoted. Maybe this is only an anecdotal example, but overly-enthusiastic populism in tech, IME, seems to have track-record of being a road to pain and sometimes ruin. https://paseto.io https://paseto.io XChaCha20-Poly1305 construction in libsodium https://download.libsodium.org/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://download.libsodium.org/doc/secret-key_cryptography/a...
- ljm 8y ago
  I don't think X509 or public key crypto is as scary as it looks, once you understand what you're actually dealing with and how the openssl related libraries work. There is definitely a UX issue though, and—without intending to be disrespectful—junior devs coming into programming through Javascript, or building basic microservices, are going to see a lot written about JWT and how easy it can be to work with, and suddenly JWT is the solution. The API for JWT in most cases is encode/decode, and you provide the payload, the options, and the key. The API for libraries linked with OpenSSL is typically a lot more verbose, so you have to understand what you need to work with, or how you might need to extract a fingerprint, convert to DER, or whatever. Beyond that, a lot of us in the web world might associate X509 with SOAP and XML, and plenty of people will avoid XML at all costs by virtue of it being XML. There's no reason why you couldn't use X509 in a JSON payload.
  - tptacek 8y ago
    I'd like to hear more about why X.509 and public key aren't scary, when the prevailing attitude in the crypto engineering community is that they're terrifying sources of surprising game-over vulnerabilities. How many people do you think there are in the world that can reliably and safely evaluate an arbitrary X.509 document in a de novo implementation?
tptacek 8y ago
In the context of security analysis, this is a vacuous statement. There's almost always something you can do to screw a security construction up. An important goal of security engineering --- and the overriding goal of modern cryptography engineering, in particular --- is to minimize the set of things that can go wrong. This is why we generally feel safer deploying Rust and Go code than C code, why we use Curve25519 instead of the NIST P-curves, and why crypto engineers generally recoil from JOSE and JWT, a set of standards that seem to have gone out of their way to maximize what can go wrong. As a telling example, compare JWT to Macaroons, a standard built effectively on one extraordinarily simple cryptographic primitive that is simultaneously safer and does more than JWT. From the vantage point of cryptographic security engineering, JWT is a cargo cult. Most projects would be better off avoiding it entirely.
- andrewstuart2 8y ago
  To be honest, and with all due respect, avoiding JWT outright feels a lot like a cargo cult to me. I have yet to see a solid argument against JWT itself, aside from the criticisms you just gave of "it doesn't minimize the set of things that can go wrong." In reality, that statement is like saying "x509 doesn't minimize the set of things that can go wrong." The criticism is leveled at JWT as if the JWT spec attempts to be anything but "a compact, URL-safe means of representing claims to be transferred between two parties," to quote the spec. I think JWT is better understood as what it intends to be, a simple standard for easily-understood claim sets, that more finely detailed, granular, and secure standards can be built atop. Admittedly, I'm reading about macaroons for the first time, but from what I can tell they're a higher level concern than something like a JWT. I'm not sure I would actually try it, because it wouldn't be very efficient, but I'd wager you could implement macaroons securely, using JWT as the container for the claims (including claimed constraints) and HMAC signatures. Maybe I'm totally off base, and if so I'd love to take the time to understand how, but I don't see how JWT as the tiny spec it is, or JWS/JWE, again rather small specs, have done anything to maximize what can go wrong, as much as they are deliberately reducing their surface area to be composable, and to allow other standards to compose them into more secure, minimally faulty specs.
  - 8y ago

kevinburke 8y ago

Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.

andrewstuart2 8y ago
I never said "all security software has flaws," since that has a substantially different meaning than my comment. While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid some of the potential downsides of pocket knives. That doesn't make pocket knives useless, it just means that you might need to be trained on safely using a pocket knife, whereas I'm totally comfortable handing a butter knife to my four-year-old. If you're going to be trusted with security, you're really going to need either a) a sharper knife, or b) to understand which knives you're okay handing to your coworkers, or c) to be able to train your coworkers on proper knife safety so they can also use the more flexible tools, but still safely.
- kevinburke 8y ago
  Well the good news is I've written about this exact subject at length! I have seen JWT implementations at five or six different companies now, tokens have never been used for more than one use case. For each specific use case you'd actually want to use it with there is a better solution that doesn't involve JWT, like secretbox or HMAC-SHA256. https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/ https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/
  - CiPHPerCoder 8y ago
    You might be happy to see the PASETO spec, which (for v2) uses XChaCha20-Poly1305 for encryption, Ed25519 for signatures, separates the two logically, and doesn't allow for runtime ciphersuite negotiation. (v1 achieves a similar result with AES-CTR+HMAC-SHA384-EtM and RSASSA-PSS.) https://github.com/paragonie/paseto/tree/master/docs/01-Protocol-Versions https://github.com/paragonie/paseto/tree/master/docs/01-Prot... It's similar to the advice given above, but also caters to that itch that some project managers have to only implement industry standards (which PASETO is slowly becoming).
    - sierdolij 8y ago
      PASETO seems to signal quality: libsodium, simple spec, platform-agnostic in the freak'n name. I keep seeing the horrors and defects of JOSE/JWT, but then it keeps getting promoted. Maybe this is only an anecdotal example, but overly-enthusiastic populism in tech, IME, seems to have track-record of being a road to pain and sometimes ruin. https://paseto.io https://paseto.io XChaCha20-Poly1305 construction in libsodium https://download.libsodium.org/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://download.libsodium.org/doc/secret-key_cryptography/a...
ljm 8y ago
I don't think X509 or public key crypto is as scary as it looks, once you understand what you're actually dealing with and how the openssl related libraries work. There is definitely a UX issue though, and—without intending to be disrespectful—junior devs coming into programming through Javascript, or building basic microservices, are going to see a lot written about JWT and how easy it can be to work with, and suddenly JWT is the solution. The API for JWT in most cases is encode/decode, and you provide the payload, the options, and the key. The API for libraries linked with OpenSSL is typically a lot more verbose, so you have to understand what you need to work with, or how you might need to extract a fingerprint, convert to DER, or whatever. Beyond that, a lot of us in the web world might associate X509 with SOAP and XML, and plenty of people will avoid XML at all costs by virtue of it being XML. There's no reason why you couldn't use X509 in a JSON payload.
- tptacek 8y ago
  I'd like to hear more about why X.509 and public key aren't scary, when the prevailing attitude in the crypto engineering community is that they're terrifying sources of surprising game-over vulnerabilities. How many people do you think there are in the world that can reliably and safely evaluate an arbitrary X.509 document in a de novo implementation?

tptacek 8y ago

In the context of security analysis, this is a vacuous statement. There's almost always something you can do to screw a security construction up. An important goal of security engineering --- and the overriding goal of modern cryptography engineering, in particular --- is to minimize the set of things that can go wrong. This is why we generally feel safer deploying Rust and Go code than C code, why we use Curve25519 instead of the NIST P-curves, and why crypto engineers generally recoil from JOSE and JWT, a set of standards that seem to have gone out of their way to maximize what can go wrong. As a telling example, compare JWT to Macaroons, a standard built effectively on one extraordinarily simple cryptographic primitive that is simultaneously safer and does more than JWT. From the vantage point of cryptographic security engineering, JWT is a cargo cult. Most projects would be better off avoiding it entirely.

andrewstuart2 8y ago
To be honest, and with all due respect, avoiding JWT outright feels a lot like a cargo cult to me. I have yet to see a solid argument against JWT itself, aside from the criticisms you just gave of "it doesn't minimize the set of things that can go wrong." In reality, that statement is like saying "x509 doesn't minimize the set of things that can go wrong." The criticism is leveled at JWT as if the JWT spec attempts to be anything but "a compact, URL-safe means of representing claims to be transferred between two parties," to quote the spec. I think JWT is better understood as what it intends to be, a simple standard for easily-understood claim sets, that more finely detailed, granular, and secure standards can be built atop. Admittedly, I'm reading about macaroons for the first time, but from what I can tell they're a higher level concern than something like a JWT. I'm not sure I would actually try it, because it wouldn't be very efficient, but I'd wager you could implement macaroons securely, using JWT as the container for the claims (including claimed constraints) and HMAC signatures. Maybe I'm totally off base, and if so I'd love to take the time to understand how, but I don't see how JWT as the tiny spec it is, or JWS/JWE, again rather small specs, have done anything to maximize what can go wrong, as much as they are deliberately reducing their surface area to be composable, and to allow other standards to compose them into more secure, minimally faulty specs.
- 8y ago