3 ms·

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 m

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?

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?