JSON Web Tokens should be avoided • Hacker News Board

Re: JSON Web Tokens should be avoided

#241

Post by tracker1 » Tue, Mar 14, 2017, 6:22 PM UTC

jdmichal wrote: post #172

StevePerkins wrote: post #70

The 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…

I can make an attempt at an alternative: Distribute signing and encryption keys to all servers. Have them encrypt and sign the outgoing serialized token, whatever that consists of. Have them verify and decrypt the incoming token. This is just straight-forward cryptography, with keys known only to the server, so I'm pretty sure you won't get any arguments from (1). (And, I suppose the encryption could even be skipped,…

And if you want to be able to authenticate users to a service that you do not want to send private keys to?

Re: JSON Web Tokens should be avoided

#242

Post by tracker1 » Tue, Mar 14, 2017, 6:25 PM UTC

jdmichal wrote: post #230

batoure wrote: post #224

Earlier quoted context omitted.

You do understand that this is fundamentally the exact underlying mechanic of JWT?

You call it the underlying mechanic. I call it the only necessary mechanic. If those additional mechanics are where the security issues come from, then just get rid of them.

No one is forcing you to accept/implement ALL possible aspects of JWT.. in fact, that's generally a bad idea... Only need to implement what you need. If a specific algorithm is bad, don't allow it...

Isn't this how HTTPS works, HTTPS today doesn't use the same SSL and algorithms allowed in 1996, it's evolved and changed in practice. The author isn't suggesting everyone just not use HTTPS because some possible algorithm has been determined to be weak is he?

Re: JSON Web Tokens should be avoided

#243

Post by zeveb » Tue, Mar 14, 2017, 6:25 PM UTC

jchrisa wrote: post #154

tptacek wrote: post #86

Earlier 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…

You are making the same mistake the IndexedDB haters made. The standardization effort around JOSE, as far as I can tell, is about making the browser a place where you can run crypto. They want it to be composable because that's the web way. I can agree with your critiques but still wish "real" cryptographers would accept the inevitability of a worse-is-better approach winning here. Don't flip tables, write the jQuery…

> The standardization effort around JOSE, as far as I can tell, is about making the browser a place where you can run crypto.

The problem is that the browser is not a place where one can safely run crypto.

> Don't flip tables, write the jQuery of web crypto. You'll do more good in the long run going with the flow on this one.

That's a bit like advising a vegan to invent a better method for slaughtering cattle (n.b.: I am not a vegan and have no problem killing & eating animals). The problem is that no-one who understands security thinks that in-browser crypto is a good or safe idea, and thus no-one who understands security wishes to help it along. It should be stopped, not made slightly less bad.

Re: JSON Web Tokens should be avoided

#244

Post by Alex3917 » Tue, Mar 14, 2017, 6:25 PM UTC

theptip wrote: post #240

Alex3917 wrote: post #149

Earlier quoted context omitted.

> 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.

> So every user on your system has to reauthenticate if one client token is compromised?

No, because you would also store either a separate datetime or uuid on each user model. And if just one user has their credentials compromised, then you would bump the date or generate a new UUID for just that user.

The global datetime would only be bumped if some site wide vulnerability were found.

Re: JSON Web Tokens should be avoided

#245

Post by tracker1 » Tue, Mar 14, 2017, 6:26 PM UTC

tptacek wrote: post #235

tracker1 wrote: post #229

Earlier quoted context omitted.

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 rea…

But any given algorithm today may not be sufficient tomorrow... so we just don't use ANY encryption? JWT is a perfectly valid structure.. there are options as to signing, so use/limit as needed.

Re: JSON Web Tokens should be avoided

#246

Post by tracker1 » Tue, Mar 14, 2017, 6:37 PM UTC

tboyd47 wrote: post #104

StevePerkins wrote: post #70

The 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…

The article very clearly is about the standard , not a particular JWT library. Server-side session tokens stored in the database worked fine ten years ago, and they work fine today. No need to muck with the load balancer. Stateless tokens are great too, and use two-factor auth when you need that extra layer of security. No need for newfangled standards; HTTP Basic remains a simple and effective way to convey that tok…

Except there are now many instances where no single database server can keep up with request load. It's not fine in all cases today. Where I work now a single request from the user goes into a pipeline of requests (some can be parallel, others not)... our SLA is X, everything that adds up to the total request time counts. Adding even 2-3ms for each service layer to verify session keys is too much.

This is as opposed to you do use.

Re: JSON Web Tokens should be avoided

#247

Post by tracker1 » Tue, Mar 14, 2017, 6:39 PM UTC

gregpardo wrote: post #96

StevePerkins wrote: post #70

The 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…

For number 2, you could expire them by encoding some identifier based off a hash or key tied to the user object. Change that object and have the server reject the token if that meta data no longer validates.

Or have really short lived tokens, requiring regular refresh, and don't worry about expiring them... you can then delete the refresh token so it can't be found requiring full re-auth if necessary.

OAuth2 + JWT is fine... just whitelist the algorithms you allow and use HTTPS for all communications, even internal.

Re: JSON Web Tokens should be avoided

#248

Post by tracker1 » Tue, Mar 14, 2017, 6:41 PM UTC

meddlepal wrote: post #90

StevePerkins wrote: post #70

The 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…

I feel like the argument against #2 is usually purely hypothetical in nature. I really do not have a problem maintaining a small lookup cache for revocations. I feel like the argument against doing this tries to take the form of all server-side kept state is bad when in reality it's sticky state and huge object graphs (read: memory consumption) that get stuffed into session objects that are the real evil. A server wi…

Or better, have a really short lived requirement for server-server jwts (I suggest even 1m, having a new one per request).

For client-server a 5 minute refresh is fine, as long as you do a lookup for refresh, so you can expire refresh tokens, requiring a full re-auth.

Re: JSON Web Tokens should be avoided

#249

Post by theptip » Tue, Mar 14, 2017, 6:43 PM UTC

tptacek wrote: post #77

StevePerkins wrote: post #70

The 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…

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…

I appreciate that this comment is wise from a cryptosystems perspective, i.e. there are a number of ways to do JWT wrong, not enough safety guards, etc., but is there not a subset of JWT that is safe to use?

The OP article makes it sound like it's impossible to use JWT correctly, but I was under the impression that if I 1) am the issuer, and 2) I hardcode a single algorithm on my API endpoints, that neither of the issues in the OP apply. (The EC issue would apply if that algorithm was chosen).

Is there a safe subset of JWT? And isn't there value to small players in using the safe subset of JWT which is battle-hardened by guys with big security teams like Google?

Re: JSON Web Tokens should be avoided

#250

Post by tracker1 » Tue, Mar 14, 2017, 6:44 PM UTC

dkersten wrote: post #125

Chris2048 wrote: post #119

Earlier quoted context omitted.

Could you just have per-server tokens? Wouldn't a single client tend to hit just one server anyway?

Wouldn't a single client tend to hit just one server anyway? No? Maybe? It depends on your load balancer. Assigning a client to a specific server is "sticky sessions". Many of us don't want to tie a client to a specific server and prefer a completely stateless 12-factor-style mechanism where any server can serve the client and stateless tokens provide a mechanism to achieve this.

Not to mention the challenges with multi-region replication needs... to do this for every request along a server-server pipeline adds more latency still, since each request to the db means potentially 2-3ms on top of more complex requests, which all adds up.