1. 1
  1.  

  2. 3

    I only looked at the linked slides (https://loige.link/jwt-crack-ny). It seems there are a number of problems there, some seem especially worrying:

    • the iat/nbf are not strings as shown in the examples
    • there seems to be a discussion on the secret length for HS256, there shouldn’t be! There is only one correct secret length (32 bytes random data);
    • RSA is recommended over HS256, which is silly as it has a different use case. (Mis)using RS256 for a situation where HS256 would suffice is silly and RSA is much less secure than HS256 for the case where the issuer is also the verifier… also we have EdDSA (RFC 8037) which is much preferred for public key signatures;
    • they recommend using it for sessions/cookies… which is a bad idea!

    Some sources:

    Update: be less mean.

    1. 2

      they recommend using it for sessions/cookies… which is a bad idea!

      Pasted from my comment on a different thread.

      I think I disagree.

      Use in a cookie. Store just enough to identify what the user has proven (e.g. enough to identify the account), join with account details later, and force the encryption type. Just because the standard says you must allow forcing insecurity doesn’t mean you must let your code listen to tokens issued by anybody (EDIT: and arguably the standard except for the good options should be ignored).

      Often enough session management is the only local state for an application, and all the other data could permit horizontal scaling (fault resiliency) if only the session database didn’t need to persist across the instances. Often, in my experience, the session database is in fact an entirely different infrastructure need such that new infra needs to be deployed to handle just that one aspect.

      Wouldn’t it be nice to forget about sessions except for the current authed user and what they want to GET now?

      If I didn’t have JWTs, I’d need to recreate them.

      1. 2

        This is exactly what we ended up doing

        1. 1

          How has it worked out for you?

          1. 2

            So far so good, we use the strictest setting possible (SameSite, HttpOnly, Secure)and only uuids inside the. We might want to switch over to JWE and encrypt it, the JS code never needs to look inside. All the AAA code is implemented on the backend side and we have calls like /api/who-am-i etc. I cannot complain.

        2. 1

          Well, if after reading this and this you still think so, good :) There may be use cases not covered in those articles, or you don’t need certain “session features” like for example revocation, or you operate at such a scale that it actually makes sense… In that case, go for it :)

          1. 1

            Yes, if I needed revocation I would need to restructure, or engineer a solution. But how much information does a session really need? Do I need to know what queries a person just ran, or what their last known IP address was?

            Why not just join a known user ID with the user record/ permissions on the server? You’d need to do it anyway, and this way you don’t need session storage.

          2. 1

            Often enough session management is the only local state for an application, and all the other data could permit horizontal scaling (fault resiliency) if only the session database didn’t need to persist across the instances.

            No.

            Really, no.

            Don’t use JWTs as a “stateless” session. Don’t use JWTs for sessions at all. In fact, best not to use JWT for anything, because it’s inherently unfit for any security-related purpose.

            1. 1

              People keep posting the same few links thinking they are making a new argument. One man’s analysis does not gospel make.

              The standard is flawed. This is established. Being standards compliant is anti security. This is established. But you don’t need to be fully compliant with the standard to have a good stateless user authentication token.

              1. 1

                But you don’t need to be fully compliant with the standard to have a good stateless user authentication token.

                The point of the first two links is that “stateless user authentication token” is not a great use case for JWT and is, in fact, something JWT is actively bad at, because you have to invent a bunch of other out-of-band stuff and/or accept a number of usually-unacceptable security compromises to keep it stateless.

                The point of the last link is that there’s no such thing as a safe JWT implementation. Even ones written by domain experts have had significant bugs which trace back to fundamental mistakes in the design of JWT. Hence my statement (the last link is to a rant by me) that JWT ends up, at best, being either a reimplementation of signed cookies or a reimplementation of bearer tokens, and generally you don’t get the “best” case.