No they shouldn't, and stop spreading FUD. First of all, the headline has a blanket statement that they should be avoided, whereas the article says don't use them for sessions (which I agree with). There are many other uses for JWT that aren't sessions. The vulnerabilities the article brings up were quickly patched in all major libraries quite a while ago.
JSON Web Tokens should be avoided
231–240 of 304 posts
Re: JSON Web Tokens should be avoided
#232JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.
* MessageVerifier defaults to SHA1. That hasn't been a good default for a few years now. * It doesn't support expiry as a claim; you have to check it against the current time manually, and factor in leeway if you want that. Because no one ever screwed up a timestamp check. * It doesn't support any other verifiable claims, for that matter, so if you want to add e.g. issuer and issued-at, you'll have to do so manually.…
1. https://github.com/rails/rails/blob/master/activesupport/lib... feel free to change the default, if you find enough reasons for rails team (beware: it's hard).
2. it doesn't, internal session class does and IMO most apps do not need expire claim.
3. Just put issuer/issued_at/whatever in your object
4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code not "maintaining your crypto fork" but merely helpers.
5. JWT has more LOC inside, say header payload is just useless. I believe having OpenSSL::HMAC helpers is better and simple enough to not do it wrong
Re: JSON Web Tokens should be avoided
#233Earlier quoted context omitted.
Hmmm, using a database (eg PG) for the authoritative information, with memcached in front sounds like it would be practical for most uses.
Probably not. If the Pg instance is replicated, as indicated above, it'll be challenging to keep the Memcached copy in sync. In other words, you can't just use the caching feature of your ORM, you'll need another piece.
Thanks, that does need further thinking about. :)
Re: JSON Web Tokens should be avoided
#234Earlier quoted context omitted.
"Better than XML-DSIG" is not a reasonable bar. Your description of the protocol is as damning as mine is.
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.
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.
Re: JSON Web Tokens should be avoided
#235Earlier quoted context omitted.
1. The reason AS::ME can be that nice is because it assumes a monolithic architecture and a single framework. For example, AS::ME relies on shared secrets, which I think makes it unfit for distributed systems. Implementing JWK with asymmetric keys can really reduce provisioning and configuration costs. Keeping the signing secret on one private, hardened auth server (or cluster) also allows smart things like automated…
Agreed... my first two experiences with JWT were creating my own implementation... in my case, the allowed public keys had to come via https from a specific server in the domain, even without PKI using shared key... I had hard coded the algorithm used for the signature. This could just as easily be filters on a library though, it's just my first experience didn't have a valid library, so I had to composite one (did u…
No, almost everybody in the field laments SSL and TLS. It's probably too late at this point --- and has been for well over a decade --- to get to something better than TLS, and so TLS 1.3 is what we're stuck with. But that is demonstrably not the case with JWT. We don't have to convince all the browser vendor to upgrade out of JWT in lockstep. Avoiding another 20 years of hair-on-fire crypto vulnerabilities seems reason enough to lobby against that spec.
Re: JSON Web Tokens should be avoided
#236The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
What's difficult about setting up a Redis cluster to back sessions? Yes, it adds a point of failure... so does having a database of any kind. However, I'd hardly call it difficult. If you're on Amazon, you can just create an Elasticache cluster and not even concern yourself with the ops. I don't hate secure cookies or anything, but some people act like plain-old regular cookies haven't been thoroughly solved by this…
JWT signature verification usually takes less time than the network request to a redis server... assuming it's non-local, because HA.
Re: JSON Web Tokens should be avoided
#237Earlier quoted context omitted.
* MessageVerifier defaults to SHA1. That hasn't been a good default for a few years now. * It doesn't support expiry as a claim; you have to check it against the current time manually, and factor in leeway if you want that. Because no one ever screwed up a timestamp check. * It doesn't support any other verifiable claims, for that matter, so if you want to add e.g. issuer and issued-at, you'll have to do so manually.…
1. https://github.com/rails/rails/blob/master/activesupport/lib... feel free to change the default, if you find enough reasons for rails team (beware: it's hard). 2. it doesn't, internal session class does and IMO most apps do not need expire claim. 3. Just put issuer/issued_at/whatever in your object 4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code no…
Thanks for your response.
> 2. it doesn't, internal session class does and IMO most apps do not need expire claim.
If you're generating a token to send to an SPA or native app, you can't rely on any other expiration mechanism. It needs to be embedded in the token or stored server-side in a database-backed session or what have you.
> 3. Just put issuer/issued_at/whatever in your object
You're missing the point that these features would require additional SLOC to verify the "claims."
> 4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code not "maintaining your crypto fork" but merely helpers.
By this logic, ruby-jwt isn't crypto, just helpers. It seems to be frowned upon simply because it includes additional features some people may not need, and those features and alternative signing methods require more SLOC than your presumed "optimal" implementation. Do you see no value in a flexible, reusable library?
> 5. JWT has more LOC inside, say header payload is just useless. I believe having OpenSSL::HMAC helpers is better and simple enough to not do it wrong
How can critics justify the position that people should write their own OpenSSL::HMAC helpers because they can't correctly call the JWT helpers?
Re: JSON Web Tokens should be avoided
#238Earlier quoted context omitted.
What happens when that replication breaks? Can people still log in? Can you still validate their sessions? Or are you going to have an outage in a geographical region?
Fall back to connecting to the main instance directly
And if the replication is down because the main instance can't be reached for a minute?
Re: JSON Web Tokens should be avoided
#239Earlier quoted context omitted.
That post is great work. Thanks again. But I think you're wrong about JWT. The problem with JWT/JOSE is that it's too complicated for what it does. It's a meta-standard capturing basically all of cryptography which, as you've ably observed (along with Matthew Green), was not written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of…
What should I use instead? I pass around JWTs attached to HTTP requests that represent an authenticated user, and contain things such as a user's email, groups, scopes etc. I've tried to keep it simple (RSA, SHA256, nothing interesting), and use the subset of JWT that seems sane (basically the bits I see Google using in their JWT based OAuth flow) I used JWTs because 1. I like the statelessness of JWTs (though I've l…
SPKI (RFCs 2692 & 2693) offers a well-developed, well-thought-out framework which meets all your needs: SPKI certificates can contain state, and thus support server statelessness; SPKI certificates can be used as OAuth tokens; SPKI certificates support custom claims (and in fact go so far as to define a well-formed claim calculus which can be implemented easily, and which supports just about anything one would wish to do); and SPKI certificates are far, far simpler than X.509.
Take a look: https://tools.ietf.org/html/rfc2692 & https://tools.ietf.org/html/rfc2693
Re: JSON Web Tokens should be avoided
#240Earlier quoted context omitted.
I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that. The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, yo…
> they may keep you up late on a Friday scrambling to deploy a token blacklist Because every token has an iat datetime, you don't need a token blacklist to invalidate tokens. You just need some sort of tokens_invalid_if_issued_before_datetime setting that gets checked whenever you validate the signature of a token. The alternative is to store a UUID for each user, and just rotate those whenever they log out, change o…
So every user on your system has to reauthenticate if one client token is compromised? That seems like an invitation to a thundering herd. Not necessarily fatal, but I'd consider it a nice feature to not have to invalidate everybody's tokens to get at one.