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

Stop using JWT for sessions (2016)

cryto.net

Post reply on HN
Print view View original

191–200 of 255 posts

Re: Stop using JWT for sessions (2016)

#191

Post by EADGBE »

detaro wrote: post #181
cryptica wrote: post #171

Earlier quoted context omitted.

This article is propaganda. This is not the first article of its kind; they just keep popping up over and over on HN with the same poor arguments. I usually take the time to write long explanations as to why these points are invalid but I'm tired of arguing with these people. The real reason for these articles I think is that some developers had a very traumatic experience with a poorly implemented JWT authentication…

Could you explain why they're important for WebSockets? Hadn't heard about them in that context before.

My guess is that a database read/write isn't necessary with JWT, and so WebSockets flying by in a scaled system aren't impeded by this extra layer of complication.

Re: Stop using JWT for sessions (2016)

#192

Post by deathanatos »

yen223 wrote: post #76
deathanatos wrote: post #52

Earlier quoted context omitted.

You shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.) (Now, if you mean looking up a session token in a database and checking that for expiry, then yes, that works, but the only real difference between JWT and tokens then is the latter requiring a database query.)

The more important difference between JWT and tokens is that the former requires you to trust that your encryption mechanism is foolproof, whereas the latter doesn't.

Session tokens (an unguessable identifier that identifies server-side stored session data), while they don't need to be encrypted or signed, the identifier should usually be cryptographically random, however, so you can still get into trouble there.

JWTs don't have to be encrypted. (And IME, typically aren't.) They need to be signed, but the algorithms that do this are common, well-understood algorithms. Some of them are likely being used by TLS to protect your session anyways. If they're not foolproof, you have bigger issues than JWT.

If you are referring to the implementation, then sure, but the same concerns exist about your implementation of TLS, and the same advice applies: use a well-known, hopefully well tested library.

Re: Stop using JWT for sessions (2016)

#193

Post by enraged_camel »

kbenson wrote: post #180
enraged_camel wrote: post #175

Earlier quoted context omitted.

>>Changing the static token causes all JWT token verifications to fail (since the token is stored in the JWT),so requires each user re-auth on the next request. So if a single user's token gets compromised, you force ALL users to log in again?

No, you force the JWT to be verified against the DB, which might be as simple as checking if the JWT creation time is older than the password update time in the DB, and if so, force only those users to log in. All the token does is force some extra level of scrutiny. It doesn't mean the JWT has to be invalidated,but it does give you the ability to selectively invalidate specific ones for the cost of extra DB load onc…

I see. Thank you for clarifying. :)

Anyway, I'm still not convinced because when it comes to security I feel like it's a better idea to walk the well-trodden path, rather than invent new and exciting mechanisms. JWTs are useful for other stuff, but using them for security requires increasing back-end complexity quite a bit.

Re: Stop using JWT for sessions (2016)

#194

Post by haloux »

None of what the author is writing about concerning the inability to revoke stateless tokens is particularly novel. We have the same problem with SSL/TLS PKI. Once a cert is revoked, there is no reliable way to ensure that its revocation is enforced among all clients. The world has proved to be content with accepting this risk.

Protip: be sure to read what I said before you use the b-word in your responses.

Additionally, the sarcastic flowchart that is included in part 2 of his post makes some pretty open-ended assumptions. "Just take down the blacklist server" is my favorite.

edit: clarification.

Re: Stop using JWT for sessions (2016)

#195

Post by indeyets »

dchest wrote: post #187
tschellenbach wrote: post #167

Earlier quoted context omitted.

The article exaggerates these issues. Also there are easy solutions available for those concerns. It's trivial to store a token version on your user object and invalidate any token that has the wrong version.

Then just store session ID there and get rid of JWT.

There's big difference between fetching session from db and validating id via short local (push distributed) revoke list. Well, that's if project is large enough to saturate storage :)

Re: Stop using JWT for sessions (2016)

#196

Post by floatrock »

ale_jrb wrote: post #169
kbenson wrote: post #158

Earlier quoted context omitted.

> > You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with. I'mnot sure that's entirely true. It's not hard to include an extra static token within the JWT which is delivered to the servers through an alternative method (pushed with production, or man…

This is true, but kicking off a large subset of the userbase every time an account is compromised (or more realistically, every time someone changes their password—which should certainly invalidate their old tokens) isn't going to be a valid trade off for most applications with customers.

A 'standard' JWT claim is Issued-At ('iat'). If you want lightweight JWT's, you're going to be loading minimal user data serverside anyways (logging, roles, etc.) -- it's trivial to compare the iat timestamp to a 'last change' field in your user object.

Of course, this gets to the point of the article -- if you're loading data serverside, that's not reeeaaallly the intended multi-party-claim-exchange use case of JWT's....

Re: Stop using JWT for sessions (2016)

#197

Post by anon1252 »

redbeard0x0a wrote: post #130
anon1252 wrote: post #21

The idea of JWT is basically you give your user a "token" that can be used against many "services" while servers don't have to persist the state of that token, just be able to read the encrypted token, and trust the information in the token. The obvious issue is the server cannot easily revoke that token without blacklisting it, therefore persisting that token somewhere on a blacklist on the server. If you are going…

Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs)

> Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs)

I don't see why one can't use redis to persist sessions at first place and why your list of revoked token would be limited to 100.

Re: Stop using JWT for sessions (2016)

#198

Post by ldng »

cryptica wrote: post #171
abledon wrote: post #68

Earlier quoted context omitted.

How the heck did JWT get such a following with issues like these?

This article is propaganda. This is not the first article of its kind; they just keep popping up over and over on HN with the same poor arguments. I usually take the time to write long explanations as to why these points are invalid but I'm tired of arguing with these people. The real reason for these articles I think is that some developers had a very traumatic experience with a poorly implemented JWT authentication…

> I usually take the time to write long explanations as to why these points are invalid

Could you link to one of your long explanations ? I'm interested in a rebutal but understand it's annoying to repeat yourself.

Re: Stop using JWT for sessions (2016)

#199

Post by zandl »

ale_jrb wrote: post #155
xae342 wrote: post #136

Earlier quoted context omitted.

This may not be part of the spec per se but you can invalidate them by distributing a bloom filter with revoked tokens and validation times, services just need to poll the service at the granularity needed. This makes scaling still much simpler than one big session store.

The problem, as the linked 'Slightly Sarcastic Flowchart' says, is: how do you handle the invalidation server going down? If you just assume that tokens are valid in this case, then an attacker just has to kill the server and they're back to being impossible to invalidate. If you assume they're invalid, you're back to having centralised state, which mostly defeats the purpose.

It’s largely irrelevant because the revocation bloom filters are cached on each service, and if the auth service is down then tokens can’t be revoked anyway so the list is still accurate enough.

TBH I don’t think the author of the article has expirenced the nightmare that is a hot session store at a large scale before, you end up with needing to troubleshoot IO latency issues with basically no tooling that can show you where the problem is and you’re up against the hardware limits and what ever black box your cloud provider has made. Where as with JWT everything happens in normal user space and can be reasonably reasoned about with a bit of complexity without razor thin latency deps on IO performance.

Re: Stop using JWT for sessions (2016)

#200

Post by AsyncAwait »

joshstrange wrote: post #78
anonymousJim12 wrote: post #15

Earlier quoted context omitted.

How do you encode it in such a way that you can invalidate individual tokens? How do you distribute that information among your services?

The way we do it is with a long lived JWT (LLJWT) and short lived jwt (SLJWT). Our LLJWT lasts for a long time (think years) and is only able to to request a SLJWT, it alone has no abilities. Inside the LLJWT we store a UUID that we also store in the DB. The SLJWT is only valid for 1hr (we are testing on bringing that down to like 10min or so) and when it expires you have to use the LLJWT to request a new SLJWT. If a…

Right, but then you just added state and re-invented sessions, in a round-about way.
Post reply on HN