Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens should be avoided

paragonie.com

Post reply on HN
Print view View original

291–300 of 304 posts

Re: JSON Web Tokens should be avoided

#291

Post by Chris2048 »

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.

> and stateless tokens provide a mechanism to achieve this

without revocation. What's wrong with tieing a client to a server, or co-located server? Either they are close enough to share tokens / sync fast, or not?

Re: JSON Web Tokens should be avoided

#292

Post by Chris2048 »

rblatz wrote: post #148
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?

What if you are running dozens of services each specializing in its own domain? Do you proxy each service through a pool of central webservers? Or do you just stand up a central auth server and have each service trust that auth server?

The latter makes sense to me. Auth is a cross-cutting concern.

Re: JSON Web Tokens should be avoided

#293

Post by jdmichal »

tracker1 wrote: post #271
jdmichal wrote: post #259

Earlier quoted context omitted.

Then sign / encrypt the token with a private key and distribute a public key to the untrusted peers. Since you're just using bog-standard cryptography primitives you can change them at will to match your use case. Need to handle untrusted peers? Asymmetric keys are the answer.

Or, you use the asymmetric key/pair to sign the JWT, and lock your environment to only public keys signed by your DC's cert in your org. If only that was supported by JWT.. oh, that's right, it is. Nobody has to implement the FULL spec, you only need to allow what your environment needs.

I'm not really sure what your point is, other than an apparently fervent desire to prove JWT's worth while speaking down to me. I didn't say that JWT couldn't do that... You're the one who set up the strawman of untrusted parties, then gleefully knock it down after I address the issue. You have contributed no other valid feedback to my proposal, just a defense of JWT which is not an answer to anything I ever stated.

I just want you to know that such tactics are not very appreciated from this side of the conversation.

What does JWT provide that using bog-standard crypto primitives in the way I described doesn't? Other than a name and a standard?

Re: JSON Web Tokens should be avoided

#294

Post by jdmichal »

tracker1 wrote: post #242
jdmichal wrote: post #230

Earlier quoted context omitted.

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

> No one is forcing you to accept/implement ALL possible aspects of JWT.. in fact, that's generally a bad idea...

I think this is a very interesting, because it's basically validating the article's argument. People are going to feel safe implementing JWT because it's an RFC, without knowing where these "generally bad idea" landmines are. That's the dangerous part.

And yes, the same issues exist in SSL / TLS. And guess what? There's loads of articles just like this one stating how dangerous older modes of these protocols are. Articles like this and the discussions they spawn are exactly the kind of thing necessary to move the world forward into safer implementations.

Re: JSON Web Tokens should be avoided

#295

Post by caivvoacmh »

tptacek wrote: post #180
danjoc wrote: post #161

Earlier quoted context omitted.

>that rebuts the (I think sort of silly) presumption that whatever an app uses needs to be RFC standardized. I thought crypto mantra was "Never roll your own." An RFC (Request For Comments) is a literal attempt to follow that advice by seeking the advice of cryptographers who are presumably smarter at coming up with crypto standards. Where were the cryptographers during the draft phase when comments were being solici…

I don't care about these moral arguments. I'm making a simple, positive claim: JWT is bad. You can blame whoever you'd like for it being bad, but as engineers, you need to understand first and foremost that JWT is bad, and reckon with your feelings about that later. You have a responsibility to built trustworthy systems, and you get no pass on building with flawed components simply because you wish experts had made t…

Does this mean that using AWS Cognito [1] is out of the question since it uses JWT? Unfortunately, you can't change what the service uses as it's all under Amazon's control.

[1]: https://docs.aws.amazon.com/cognito/latest/developerguide/am...

Re: JSON Web Tokens should be avoided

#296

Post by andy_ppp »

CiPHPerCoder wrote: post #276
andy_ppp wrote: post #261

Earlier quoted context omitted.

Yes but you can now concentrate make yourself XSS proof right; with an XSS you can still get someones cookies... unless you are talking HttpOnly. But we are probably talking single page webapps here anyway.

> unless you are talking HttpOnly Which is precisely what the blog post that was hyperlinked in the sentence you were responding to was advocating.

If there are no XSS attacks against ReactJS then both ways protect me from both CSRF and XSS right?

If you can show ReactJS XSS then I may need to reconsider.

Re: JSON Web Tokens should be avoided

#297

Post by robertlagrant »

stephenr wrote: post #289
robertlagrant wrote: post #287

Earlier quoted context omitted.

I wouldn't say it's impossible to invalidate them individually. It's certainly more effort, and it's probably better to have short-lived session tokens and refreshing, but I think it can be done. E.g. what about a message bus that publishes an invalid token message that is subscribed to by the API-providing systems, so they can maintain a prematurely-expired tokens list? On the keeping info in Javascript vs keeping i…

> I wouldn't say it's impossible to invalidate them individually It's impossible to invalidate individual "stateless" JWT's. If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole…

(Feel free to bail on this at any time if my questions/suggestions become tiresome :))

> If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole purpose of using JWTs (being stateless).

While I agree that it's no longer stateless, JWT's still really useful in terms of not needing a centralised auth/auth provider that everyone has to hit to see if I am who I say I am and whether I'm allowed to call an API. And a message bus is a pretty good compromise between the extremes of big wide systems that share state and microservices that don't talk to anything else.

> Cookies can be set HTTP only ... session cookie. Thanks - I get what you're saying.

> If the data can be read from the network by your JavaScript, it can be read from the network by their JavaScript. Yeah. I think I see what you mean. Assuming you don't mean literally "reading data from the network", as I assume the problem isn't the network access but the access to the security info, are you saying that hostile Javascript on the page can read everything and call everything that legitimate Javascript can?

If so, I can't tell the difference between that and - say - a CSRF token, which presumably can also be read by "their" Javascript? How does anything work if you have that mentality?

Re: JSON Web Tokens should be avoided

#298

Post by jchw »

tracker1 wrote: post #236
jchw wrote: post #147

Earlier quoted context omitted.

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.

I'll just say this: if the most expensive part of your API is calling Redis, it probably doesn't have anything worth authenticating for in the first place.

Re: JSON Web Tokens should be avoided

#299

Post by stephenr »

robertlagrant wrote: post #297
stephenr wrote: post #289

Earlier quoted context omitted.

> I wouldn't say it's impossible to invalidate them individually It's impossible to invalidate individual "stateless" JWT's. If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole…

(Feel free to bail on this at any time if my questions/suggestions become tiresome :)) > If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole purpose of using JWTs (being statel…

> not needing a centralised auth/auth provider

The vast majority of people don't need the scale that is difficult to achieve with regular server-side sessions, and that JWT claims to "solve". They add complexity to solve a problem most people don't have.

> I can't tell the difference between that and - say - a CSRF token, which presumably can also be read by "their" Javascript

CSRF is about e.g. making a user's browser make a form submission that results in a request which is malicious in some way. CSRF Tokens are embedded in each legitimate form to ensure that the submission received came from a form you control.

If the attacker has JavaScript access to your page, CSRF is not your problem, so CSRF tokens can't help you.

Re: JSON Web Tokens should be avoided

#300

Post by stephenr »

jchw wrote: post #147
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…

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…

The problem is you're suggesting real-world, ops-capable solutions to a problem "Devops" (as in, developers can do it, we don't need ops) people don't want to understand because they'd rather jump on yet another poorly designed "solution" to a problem they don't really have.
Post reply on HN