4 ms·

I did wrap JWT/JWE with a library lest somebody else in my company would get the bad idea to implement directly, and yes, the first thing I've done was to limit

I did wrap JWT/JWE with a library lest somebody else in my company would get the bad idea to implement directly, and yes, the first thing I've done was to limit the signing algorithm to a single specified algorithm (HS256 for everything that doesn't have to cross service boundaries). But I admit never thought of it as a particularly bad crypto protocol. It's actually pretty good compared to most negotiable crypto standards out there. I mean, yeah, JWK allows you to embed X.509 (but you don't have to do it), the value of supporting RSA is questionable, their selection of curves is regrettable (but all the world went with the NIST curves), compression on JWE (and not JWS?!) makes me suspicious, and yeah, JSON is kinda verbose compared to MsgPack et al. But then I remember that before that before JWT came SAML+XML-DSIG (and the whole WS-* ecosystem) and CMS/PKCS#7 (and the whole ASN.1 ecosystem). Ah, compared to these JOSE is a fresh breath of air. What a lightweight and uncomplicated serialization format - It couldn't even be used for amplified DDOS attacks! What a modern set of ciphers (besides 'none', sorry, missed that on there ;). No more DES, RC4, or unpopular untested ciphers just there to fill the slots. Yeah, JOSE still has some parts which are over-engineered but for a STANDARD it's the best one there. Management demands standards, it's a fact of life. And I'd choose JWT over SAML or CMS any day.

tptacek 10y ago
"Better than XML-DSIG" is not a reasonable bar. Your description of the protocol is as damning as mine is.
- unscaled 10y ago
  Agreed, but is there a better standard? I'm also fine with just stuffing MsgPack or Cap'n Proto data inside a libsodium secretbox or usually just crypto_auth to be honest, but corporates love standard. Perhaps libsodium algorithms should be turned into RFCs and then we could have a much simplified token metadata format (expiry, issued date and their ilk) that can be separated from a completely freeform payload. I'd gladly push that format over JOSE. We can cry "just run an arbitrary format through HMAC-SHA256/libsodium" until the end of the days, but it's the same as asking developers to just send a list of key-value pairs during the XML overengineering heyday. Until JSON came with RFC hammer on their head, developers went with XML by default.
  - tptacek 10y ago
    Sure: use Fernet. https://github.com/fernet/spec/blob/master/Spec.md https://github.com/fernet/spec/blob/master/Spec.md It's an informal standard, like Noise, or WireGuard, or Curve25519, or Nacl. It's also so simple that JWT nerds will likely believe it's missing something. It is: the JWT/JOSE vulnerabilities. It used to be that we got things working and then standardized them. Now we build cryptosystems de novo in standards committees and spend the next 10 years writing papers about the resulting flaws. Ok, it didn't used to be that way, and we've always been writing papers about flaws in crypto standards. I don't know what to say about this, except "stop, somehow".
    - unscaled 10y ago
      Yes, informal standards, but that's exactly the problem. At my previous work, I've implemented something similar to Fernet in the past (though using AES-GCM rather than AES-CBC+HMAC), and that's dead simple. But it's not standard. Every time I've suggested modifying our JWT implementation to use Ed25519, or using any NaCL implementation for encryption instead of the vulnerability-footgun framework better known as JCE, I get raised eyebrows. People want standards. Fernet is nice, but it should be pushed to an RFC level and offer more metadata besides a timestamp (not hard, just copy all the JWT claim names in stick a JSON into the ciphertext :)) It's also not useful when you do need asymmetric encryption/signature, and you can't just ignore these use cases, since people will keep JWT alive just for them.
- davewritescode 10y ago
  As shitty as XML-DSIG is, it's pervasively used across almost every single language and platform imaginable. The goal of standards like JWT and XML-DSIG is interoperability above security. What good is perfect security if you can only talk to yourself? PS: libsodium is great but the fact that it requires C bindings to use from a JVM app makes it a non starter for a lot of use cases.
  - tptacek 10y ago
    I don't know how to respond to this in any other way than to say that it's unethical to build systems you know have security weaknesses.
    - davewritescode 10y ago
      1 - You have not demonstrated in anyway that it's impossible to use JWT tokens in a secure manner. Just that it's easy to shoot yourself in the foot. 2 - It's not unethical to make tradeoffs, period. We all build systems that have potential attack vectors and we make tradeoffs based on threat models. That's the difference between Academics and Engineers. Example: Hacker News allows shitty passwords, that's a security weakness. However, the data that's protected by that shitty password is pretty meaningless. Is that not a good security tradeoff? Is Hacker News unethical?

tptacek 10y ago

"Better than XML-DSIG" is not a reasonable bar. Your description of the protocol is as damning as mine is.

unscaled 10y ago
Agreed, but is there a better standard? I'm also fine with just stuffing MsgPack or Cap'n Proto data inside a libsodium secretbox or usually just crypto_auth to be honest, but corporates love standard. Perhaps libsodium algorithms should be turned into RFCs and then we could have a much simplified token metadata format (expiry, issued date and their ilk) that can be separated from a completely freeform payload. I'd gladly push that format over JOSE. We can cry "just run an arbitrary format through HMAC-SHA256/libsodium" until the end of the days, but it's the same as asking developers to just send a list of key-value pairs during the XML overengineering heyday. Until JSON came with RFC hammer on their head, developers went with XML by default.
- tptacek 10y ago
  Sure: use Fernet. https://github.com/fernet/spec/blob/master/Spec.md https://github.com/fernet/spec/blob/master/Spec.md It's an informal standard, like Noise, or WireGuard, or Curve25519, or Nacl. It's also so simple that JWT nerds will likely believe it's missing something. It is: the JWT/JOSE vulnerabilities. It used to be that we got things working and then standardized them. Now we build cryptosystems de novo in standards committees and spend the next 10 years writing papers about the resulting flaws. Ok, it didn't used to be that way, and we've always been writing papers about flaws in crypto standards. I don't know what to say about this, except "stop, somehow".
  - unscaled 10y ago
    Yes, informal standards, but that's exactly the problem. At my previous work, I've implemented something similar to Fernet in the past (though using AES-GCM rather than AES-CBC+HMAC), and that's dead simple. But it's not standard. Every time I've suggested modifying our JWT implementation to use Ed25519, or using any NaCL implementation for encryption instead of the vulnerability-footgun framework better known as JCE, I get raised eyebrows. People want standards. Fernet is nice, but it should be pushed to an RFC level and offer more metadata besides a timestamp (not hard, just copy all the JWT claim names in stick a JSON into the ciphertext :)) It's also not useful when you do need asymmetric encryption/signature, and you can't just ignore these use cases, since people will keep JWT alive just for them.
davewritescode 10y ago
As shitty as XML-DSIG is, it's pervasively used across almost every single language and platform imaginable. The goal of standards like JWT and XML-DSIG is interoperability above security. What good is perfect security if you can only talk to yourself? PS: libsodium is great but the fact that it requires C bindings to use from a JVM app makes it a non starter for a lot of use cases.
- tptacek 10y ago
  I don't know how to respond to this in any other way than to say that it's unethical to build systems you know have security weaknesses.
  - davewritescode 10y ago
    1 - You have not demonstrated in anyway that it's impossible to use JWT tokens in a secure manner. Just that it's easy to shoot yourself in the foot. 2 - It's not unethical to make tradeoffs, period. We all build systems that have potential attack vectors and we make tradeoffs based on threat models. That's the difference between Academics and Engineers. Example: Hacker News allows shitty passwords, that's a security weakness. However, the data that's protected by that shitty password is pretty meaningless. Is that not a good security tradeoff? Is Hacker News unethical?