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

301–304 of 304 posts

Re: JSON Web Tokens should be avoided

#301

Post by robertlagrant »

stephenr wrote: post #299
robertlagrant wrote: post #297

Earlier quoted context omitted.

(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 brows…

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

Not really talking about sessions, but I think I see what you're saying.

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

I agree. I'm trying to understand what you were saying about whatever your Javascript has access to, their Javascript does as well. Why should this be a criticism of JWT and not CSRF?

Re: JSON Web Tokens should be avoided

#302

Post by dkersten »

Chris2048 wrote: post #291
dkersten wrote: post #125

Earlier quoted context omitted.

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?

What's wrong with tieing a client to a server, or co-located server?

Nothing, if you can get away with it. What do you do if your server dies or is overloaded? The 12-factor patterns came to be for services running on ephemeral hosts in cloud environments. Stateless servers mean you can seamlessly serve requests from another server without problem. Sure, you can store the sessions in a shared resource (redis perhaps?) but this complicated failover and redundancy and may add latency.

Maybe this isn't an issue, maybe it is. If you don't need or want that, then just use normal sessions, for sure.

Revocation can be handled (although admittedly not as well as with sessions or stored tokens) through short TTL's and refresh tokens (which are stored, but only need to be looked up when the stateless token expires). Its not perfect, but its often a good enough tradeoff.

Re: JSON Web Tokens should be avoided

#303

Post by stephenr »

robertlagrant wrote: post #301
stephenr wrote: post #299

Earlier quoted context omitted.

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

> 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. Not really talking about sessions, but I think I see what you're saying. > If the attacker has JavaScript access to your page, CSRF is not your problem, so CSRF tokens can't help you. I agree. I'm trying to und…

> Not really talking about sessions

Well, mostly a JWT lets you know the user that is signed in.

A server-side session generally does the same thing, but can be used to store larger amounts of data.

> I'm trying to understand what you were saying about whatever your Javascript has access to, their Javascript does as well. Why should this be a criticism of JWT and not CSRF?

They're unrelated attack vectors.

CSRF is about bad actors producing links and/or forms on a different site to your own, that a legitimate user clicks/submits (either through social engineering or some kind of javascript in their page) causing them to make a request to your server. A CSRF token prevents this because it ensures that form submission requests have come from a form hosted on your server.

In the situation where we're worried about what someone else's JavaScript has access to, it means their javascript is already loaded into your page: a vulnerability with poorly escaped user content, a rogue browser extension, a malicious or compromised CDN, etc.

In that situation, CSRF is irrelevant. The CS in CSRF is "Cross Site" - this is no longer cross site, as the script is running in the context of your own page.

So in this situation nothing we do can prevent them from making requests within the current user session.

But what we can prevent them from doing, is stealing a user identifying token: e.g. a session cookie, by marking it HTTP Only, so the JS environment doesn't see it.

JWT's accessed over XHR/etc and stored in local storage are available to any malicious scripts running, meaning they can grab the user's JWT and send it off to their own server, allowing them to make requests as the user.

If you send JWT's as cookies and mark them as HTTP only, you've defeated the "don't send session cookies with every request" goal of JWT, and the cookie will be bigger than most session cookies.

Re: JSON Web Tokens should be avoided

#304

Post by robertlagrant »

stephenr wrote: post #303
robertlagrant wrote: post #301

Earlier quoted context omitted.

> 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. Not really talking about sessions, but I think I see what you're saying. > If the attacker has JavaScript access to your page, CSRF is not your problem, so CSRF tokens can't help you. I agree. I'm trying to und…

> Not really talking about sessions Well, mostly a JWT lets you know the user that is signed in. A server-side session generally does the same thing, but can be used to store larger amounts of data. > I'm trying to understand what you were saying about whatever your Javascript has access to, their Javascript does as well. Why should this be a criticism of JWT and not CSRF? They're unrelated attack vectors. CSRF is ab…

> Well, mostly a JWT lets you know the user that is signed in. In my case I'm happy to use non-JWT methods to hold a user's session information (e.g. an HTTP-only cookie) and just want JWT to authenticate with other systems' APIs without needing to centralise auth/auth.

> They're unrelated attack vectors. Good point. I guess I more just meant that what can malicious Javascript do with endpoints protected by JWT that it can't do with endpoints protected another way.

> JWT's accessed over XHR/etc and stored in local storage are available to any malicious scripts running, meaning they can grab the user's JWT and send it off to their own server, allowing them to make requests as the user.

I guess this answers the above question: the difference isn't in what can be executed in the browser, but what can be shipped to a different server to be used in attacks from there.

To mitigate that, then, how's this setup:

1) User's session is maintained in HTTP-only cookies. 2) Browser can use (1) to request a JWT token (and a refresh key) to hit a 3rd-party API endpoint. The token is valid for 5 minutes. 3) Browser can use the refresh key from (2) to request another JWT token.

Does that pretty much bring it up to parity with using cookies everywhere, while keeping the goal of noncentral auth/auth?

Post reply on HN