8 ms·

Using Elliptic Curve cryptography would've resulted in much smaller signatures, libsodium is considered secure and has bindings to most sane/modern environments

• icebraining 7y ago
  Not saying the standard is good, but in this case, the author is specifying a fixed signature algorithm, so that problem doesn't apply, as far as I can tell.
• 1_player 7y ago
  That JWT link sounds like hyperbole. Can anybody chime in on whether JWT is absolutely broken as stated in the article, or, while it has some issues, the author likes being a bit too dramatic?
  • weego 7y ago
    The root of most of the points in the article is "when you use JWT for the wrong use case it is bad" which is self-evident. Other than that it is hyperbole imo.
  • pillfill 7y ago
    Unnecessarly and overly dramatic, essentially arguing that because JWT/JOSE is insecure because it can be used in an insecure manner.
  • lvh 7y ago
    JWT is multiple layers of bad. My favorite summary is that it has poor implementations of a harebrained scheme designed to solve a problem you don't have. The idea that I need to read the header, which is unauthenticated, to parse the token violates the Cryptographic Doom Principle. Has that led to vulnerabilities? Of course it has: I just said it violates the Cryptographic Doom Principle. The idea that it has everything plus the kitchen sink -- even for drastically different behavior and opinions on how the world works, from symmetric encryption to asymmetric signing and multiple implementations of each at that, is anathema to modern cryptographic design. Wireguard has one scheme and it does a lot more complicated stuff than "encrypt a session token". JWT's saving grace here is that few people implement all of it. And ... that's ... cool? Until they do, of course. You can argue that something is an implementation problem and not a spec problem. Some issues definitely are, but if every major implementation has the same damn bug, then I think it's a spec problem. Unauthenticated headers are a spec problem. PKCS1V15 enc is a spec problem. The fact that an implementation can patch around it doesn't make it not a spec problem. I'm sitting on several more vulns in ~every JWT library that are, to cryptographers, literally too boring to publish even though one of them is _key recovery_. Other posters have said that it's silly to say that merely the ability to use it unsafely is a problem. But good crypto looks exactly like bad crypto while you're doing it, and there's good crypto that doesn't have that set of problems, so why would you ever choose the poor design? (Don't use JWT.)
    • rakoo 7y ago
      So it seems that the Cryptographic Right Answers is lacking a section on "stateless tokens carrying a small payload". What should one do in this case?
      • lvh 7y ago
        I mean, part of the answer is "don't do that" but if you have to, secretbox or PASETO. Part of the problem is that "stateless token" can mean a lot of things depending on context; for internal use you generally want symmetric MAC possibly w/ symmetric encryption, for external use you probably want signing -- all of which have answers in Cryptographic Right Answers :)
        • rakoo 7y ago
          I was wondering more about how to format a payload that may be shared between agents in a standard, secure format, but that is probably not even a Cryptographic Question :)
          • lvh 7y ago
            Still the same answer unfortunately: depends on the use case. Sometimes you just want signing, sometimes it's OK to share a key, sometimes...
    • sarcasmic 7y ago
      Most people use the JWT compact serialization, which cannot carry the unprotected header at all. If you're exchanging JWT compact tokens, the header is protected by the signature or the encryption.
      • lvh 7y ago
        What? You mean protected by the _MAC_? The header is never encrypted: the header is how you even figure out what to do with the rest of the message at all. That is why it definitionally can not be protected by it (that's the definition of the cryptographic doom pricnople!) and is how the bugs I am referencing are exploited to begin with. The only sense that a JWT header is "protected" is that the spec calls it that. Have you ever exploited a JWT vuln? Which one? Because odds are there's a way it boils back down to the JWT header design choice being silly. I mean there's an easier way to have this conversation: if the header is "protected", how did the alg=none bug ever work?
• jedisct1 7y ago
  In that case, I don't see why they didn't simply use symmetric cryptography.
  • lvh 7y ago
    I asked that upthread; apparently the answer is "inspectability", they're updating the blog post to highlight that, and I have a hunch my suggestion is going to be the AD in AEAD :)
• sethvargo 7y ago
  EC isn’t widely supported on older systems, especially in enterprises: https://support.globalsign.com/customer/en/portal/articles/1995283-ecc-compatibility https://support.globalsign.com/customer/en/portal/articles/1... Yes, it’d be a smaller payload and less CPU to use EC over RSA, but EC still isn’t the least common denominator. I speculate the author is optimizing for comparability over performance which is a perfectly valid trade off to make in a blog post :)
  • theacodes 7y ago
    I actually just aimed for simplicity and stuff folks might be semi-familiar with. It might be worth adding a little note that EC would be more efficient all around.