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

Don't use JSON web tokens for sessions

cryto.net

Post reply on HN
Print view View original

141–150 of 153 posts

Re: Don't use JSON web tokens for sessions

#141

Post by kkl »

SCHiM wrote: post #133
tptacek wrote: post #80

Earlier quoted context omitted.

It does not. It is the difference between an exploit that yields a root password and one that yields a shell at uid=0. HttpOnly is almost totally cosmetic.

It's not the same, an XSS is not comparable to a shell for the exact reason I outlined above. And a session is not a password. I'm probably coming over as too offensive, but you really really don't seem to know what you are even talking about. You are wrong wrong wrong.

If you don't believe `tptacek maybe you will believe James Kettle:

http://blog.portswigger.net/2016/05/web-storage-lesser-evil-...

Re: Don't use JSON web tokens for sessions

#142

Post by zeveb »

andrewstuart2 wrote: post #47

I'm not quite sure the author of the article has a solid grasp of JWT, or identity federation in general given that he compares JWT to cookies (it's more like SAML than anything else). I'd highly recommend giving the RFC [1] a once-over to see what the spec is really about. > The correct comparisons are "sessions vs. JWT" and "cookies vs. Local Storage". This is somewhat true, but flawed. The better comparison is "SA…

> The way JWT solves CSRF is not by the way it's stored; it's by the way it's transmitted in an Authorization header, which can't be done cross-domain and won't be included by the browser (as cookies would). If you're not using JS, you shouldn't be looking at JWT at all; it's useless without it.

This isn't quite true: JWTs may also be transmitted as an access_token URL or form parameter. As such, they are not useless without JavaScript (which is good).

> > JWT tokens are not exactly small.

> They're as small as a secure cookie: metadata header + data + signature. That's it.

They're in a sadly verbose format, which by its nature tends to lead to double-Base64-encoding values. There're a lot of double-quotes and commas, which isn't wonderful. It's not a colossally-wrong format like XML, but it's not great. And it's not terribly readable, despite being somewhat verbose.

Re: Don't use JSON web tokens for sessions

#143

Post by merb »

numbsafari wrote: post #101
mwpmaybe wrote: post #65

Earlier quoted context omitted.

Invalidating the site secret is my go-to strategy right now, but I have wondered how to sign out a single user across all their logged-in devices. Anyway, this idea is interesting and would be pretty straightforward to implement. Thanks!

The point is to avoid all the database updates. So, I would recommend not going that route. If you need to sign out a user across all logged-in sessions, use a revocation list based on UID, rather than token-id.

yep probably the better idea. eventually we combine sessions and JWT Tokens. The session id is kind of a refresh token that refreshes the token if it was expired and the user didn't generate a new token in less than one minute. than it will use the session id will query the database and create a new token if the session is still valid.

Re: Don't use JSON web tokens for sessions

#145

Post by vladgur »

rahkiin wrote: post #61
vladgur wrote: post #51

Ill chime in with my $0.02 * Inability to invalidate stateless JWT tokens can be more or less be remedied with a short expiration time of the token and a token refresh flow. If a token is only valid for 5 minutes, and you can only refresh the token during that 5 minute window, it greatly reduces the attack vector. If that risk is too high, you should easily implement state with the same Redis setup that author mentio…

If you give the tokens an expiration time of 5 minutes, the application either needs to auto-request a token every 4-5 minutes automatically using a JavaScript timer, or your session times out way too quickly. If you close the tab, you will be logged out within 5 minutes. That may not be desired in many applications.

That correct. You would use the timer to auto-refresh the token.

Note: if you close the tab, if you use a session cookie for token storage, its likely to remain, but like you said will become invalid within 5 minutes.

If you close the browser however, a Session cookie will be deleted, which mitigates an issue in a shared setting.

Depending on the requirements, you can ask a user whether they are using a shared pc or a private pc and choose cookie storage at that point.

Re: Don't use JSON web tokens for sessions

#146

Post by joepie91_ »

merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

> This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it.

This refers to invalidating individual tokens. I've just updated the title and text in the post to clarify that.

> Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here.

Compared to storing something in a cookie. The article explicitly states that this concerns JWT tokens that are not stored in a cookie. And comparing "JWT vs. Cookies" makes absolutely no sense, they're different kinds of things.

> They take the same amount of storage than signed cookies, wuhu I use JWT so often and I NEVER exceeded the cookie limit, but I wouldn't store them there anyway.

Again - the article explicitly states that this refers to stateless tokens, ie. where the data is contained in the token itself. Did you actually read the full article, or just the headers?

> JWT is as secure as any other solution and this article proves it since he isn't well informed, he just throws a bunch of stuff out and tries to be "an expert". Btw. every other solution is really dangerous as well, especially Cookies could be a total mess of security problems. The same could actually happen with Bearer Tokens.

Personal attack and hand-wavy statements without ever actually addressing any specific security concerns. Take that elsewhere. I'm here for technical discussion, not for throwing shit.

> My toughts are use the thing your most happy with and the thing you understand

No, that is not how security works.

> and the thing you can implement with code that is totally clear and especially code that is really really easy to understand. And actually JWT will mostly win this battle.

No, it won't. The typical framework will only require you to load a single plugin to get sessions working, and literally nothing else. JWT tokens require manual handling.

> I've seen a lot of people just using Session Cookies from their Framework, but eventually have no idea about their risks, they have lots of CSRF all over the place

That is a separate problem, and you don't solve that by storing your session IDs differently and trying to sidestep it. You store it by actually mitigating the problem you are having, which means adding CSRF tokens.

That's the only actually secure solution to this problem - "manually handling sessions" and "secure session storage" are mutually exclusive, and automatically handling sessions will always be vulnerable to CSRF problems.

> or using a too small ID or eventually the ID is not really random.

Use a well-tested implementation - as, again, I have stated in my article - and this will not be a problem. Don't roll your own session implementation.

Re: Don't use JSON web tokens for sessions

#147

Post by niteshade »

merb wrote: post #55
numbsafari wrote: post #52

Earlier quoted context omitted.

Your first point is mostly dead on. I see a number of people stating that you cannot revoke a token, and it's simply not true. The approach I use is to replace the shared session store (which is large, grows linearly with your user base, and hard to sync across clusters if you need that) with a shared revocation list. The revocation list is small, easy to check, only contains IDs and a TTL, much less cumbersome to re…

actually I often see stating that you should rely on a 3rd party authentication library since its mostly well known and well tested. While I would agree here I know that mostly the library will be your weak point since you have no idea how its implemented or whenever a new version comes around if it maybe has a security issue or if you keep your version if your vulnerable to something. Actually most people should tak…

I actually think your advice is more harmful than helpful - web developers are not renowned for writing secure software. This is a very good case of finding a good, well-tested and vetted library that does this. Not sure what options exist, but I would be highly surprised if there weren't any already.

Re: Don't use JSON web tokens for sessions

#148

Post by mcherm »

sb8244 wrote: post #114
mcherm wrote: post #111

Earlier quoted context omitted.

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used? Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.

Not particularly. There are other layers of security here - the sessions expire (so there's a limited window to exploit each one), the sessions are always transmitted via SSL (so you pretty much have to have an exploit on the customer's system to get one), and the sessions are restricted to one customer (so you only have an attack against the customer whose system you have an exploit on).

If we used a different approach, then the same error (losing the data that's being synched) would result in losing all of the customer sessions.

Re: Don't use JSON web tokens for sessions

#149

Post by ekryski »

njknsdf wrote: post #138
low_key wrote: post #86

Earlier quoted context omitted.

I keep a counter in the JWT to at least mostly get around this issue. When processing a request, the counter is checked for the user, which isn't a big deal since all of the requests already require looking up the user. A counter increment invalidates all of that user's existing tokens. If a user changes their password, their roles change, etc, then the counter gets incremented so all tokens issued up to that point w…

You can store the user info in the JWT so you don't need to hit the database to get user info every time. I usually just store an id in each issued token and store/remove it from redis or memory as needed for invalidating it.

You have to be careful that you are not leaking sensitive info though, as the JWT payload is meant to be visible on the client as well.

Re: Don't use JSON web tokens for sessions

#150

Post by ekryski »

low_key wrote: post #86
lynndylanhurley wrote: post #69

Earlier quoted context omitted.

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

I keep a counter in the JWT to at least mostly get around this issue. When processing a request, the counter is checked for the user, which isn't a big deal since all of the requests already require looking up the user. A counter increment invalidates all of that user's existing tokens. If a user changes their password, their roles change, etc, then the counter gets incremented so all tokens issued up to that point w…

That's pretty smart. Effectively versioning your issued tokens. Way easier than maintaining a blacklist.
Post reply on HN