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

241–250 of 255 posts

Re: Stop using JWT for sessions (2016)

#241

Post by marcosdumay »

kbenson wrote: post #226
marcosdumay wrote: post #211

Earlier quoted context omitted.

Well, you are adding infrastructure to explicitly reject the tokens. It is stateful infrastructure. And you can not reasonably do that if you use the tokens as session holders. So, should I think that you agree with the article?

It is stateful, but with a minimal amount of state that is global. In that respect, it isn't "defeating the entire point of using stateless JWT tokens to begin with." The point is not to be stateless for its own sake, but to leverage less state in a way that's beneficial (e.g. not having to authenticate every request). If adding back a little bit of state in a different way mitigates the major downsides, that can sti…

To be fair, this discussion is unhealthy being full of hyperbole of both sides. Your were one of the first answers, so there was a lot of lost context.

The article has a perfectly nice point, that nearly every site does not need stateless sessions. Keeping them on the database is perfectly fine.

The article also has a point that there it is impossible to revoke certificates without shared state.

People here have a point in that it is possible to optimize that shared state as much as it is a performance non-problem.

Other people here have a point in that this is a hard problem that isn't solved by default, so you either do some low level work creating your revocation list from basically the ground up, or you'll get something that is worse than a database.

Yet other people have a point in that it's hard to set your PKI correctly and if you don't want to bother with that, you are better with a standard database implementation.

All of those are true.

Re: Stop using JWT for sessions (2016)

#242

Post by [deleted] »

marcosdumay wrote: post #241
kbenson wrote: post #226

Earlier quoted context omitted.

It is stateful, but with a minimal amount of state that is global. In that respect, it isn't "defeating the entire point of using stateless JWT tokens to begin with." The point is not to be stateless for its own sake, but to leverage less state in a way that's beneficial (e.g. not having to authenticate every request). If adding back a little bit of state in a different way mitigates the major downsides, that can sti…

To be fair, this discussion is unhealthy being full of hyperbole of both sides. Your were one of the first answers, so there was a lot of lost context. The article has a perfectly nice point, that nearly every site does not need stateless sessions. Keeping them on the database is perfectly fine. The article also has a point that there it is impossible to revoke certificates without shared state. People here have a po…

[deleted]

Re: Stop using JWT for sessions (2016)

#243

Post by tinus_hn »

cbsmith wrote: post #168
ale_jrb wrote: post #155

Earlier quoted context omitted.

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.

The bloom filter allows you to largely distribute the work of the server, and serves as a reasonable proxy during a failure off the server. More importantly though, there's no reason it need be a centralized server. Invalidated tokens could be broadcast to a wide number of servers that each maintain the invalidated token list (it's a great case for a CRDT, since it is append only with a TTL). Normally it'd be a prett…

It might even be a real use case for blockchain!

Re: Stop using JWT for sessions (2016)

#244

Post by giobox »

abledon wrote: post #68
drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

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

JWTs have long been a favourite topic of software engineer bloggers as they do raise a lot of interesting technical questions.

Whether we can take this as evidence of a big following in actual production implementations I’m not so sure, but if forced to guess I suspect they are exceedingly rare (compared to stateful systems) outside of programmer side projects.

I’ve rarely ever seen stateless auth used on anything serious, as others have noted many times before the issues with invalidating previously issued tokens often removes the “stateless” part, after which you are just as well using more traditional mechanisms.

Re: Stop using JWT for sessions (2016)

#245

Post by patterned867 »

CiPHPerCoder wrote: post #179
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…

> This article is propaganda. Someone else called it FUD, now you're calling it propaganda. I'm seeing a pattern. > This is not the first article of it's kind; they just keep popping up over and over on HN with the same poor arguments. I usually post long explanations as to why these points are invalid but I'm tired of arguing with these people. ...they said, commenting on an Internet board where discussions (a.k.a.…

> Someone else called it FUD, now you're calling it propaganda. I'm seeing a pattern.

Maybe you should talk to someone about the patterns you are seeing. Maybe you can connect more unrelated things together to paint a mental portrait of others. Thanks for being inclusive.

Re: Stop using JWT for sessions (2016)

#246

Post by KirinDave »

mgraczyk wrote: post #215
KirinDave wrote: post #143

Earlier quoted context omitted.

> Since the blacklist is just a collection of random token IDs, it isn't sensitive. You can store it anywhere, including in memory in your web servers or in a distributed cache. You can wait during blacklist/token invalidation events until the newly blacklisted token has been propagated. This is very dangerous advice. If you're advocating for the addition of a fast blacklist storage, you really haven't changed your p…

> then you need to take the integrity of that data set very seriously or be at serious risk of credential replay attacks. This is no more true in my technique than in session tokens. You have to invalidate session tokens carefully, most simply using serializable database transactions. You can do the same with the blacklist. People also put session tokens in memory, and your concern about caching and consistency appli…

> This is no more true in my technique than in session tokens.

Which is to say that it's equally true, but you're advocating for a more ephemeral storage.

> People also put session tokens in memory, and your concern about caching and consistency applies equally in that context. The blacklist is in some ways easier to manage because it is not sensitive like a session token. It's more difficult in other ways, but IMO harder to get wrong.

If you're leaking session tokens your entire authN/authZ system collapses I guess that's not wrong, but it's not clear that your invalidation session is as insensitive as you suggest. For example, if your token generator's RNG has flaws, you're essentially enabling that discovery via a public stoplist store.

Ultimately, it's weird to imagine using something like JWT and having a request-to-authZ scheme. You have all the equipment to do short-lived renewable tokens, and then you get invalidation (to the resolution of your timing) for free and better scaling properties and a whole host of other security benefits.

I personally strongly discourage people to use JWTs at all, but if you are at least take advantage of them!

Re: Stop using JWT for sessions (2016)

#247

Post by mdavidn »

zandl wrote: post #199
ale_jrb wrote: post #155

Earlier quoted context omitted.

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

I'm confused by your comment. Session stores seem like the easiest storage to scale horizontally. The workload is just a distributed hash, _maybe_ with atomic updates. "Three nines" durability over one day is perfectly acceptable. Use a consistent hash ring, no replication, and add nodes until you achieve the performance required.

Re: Stop using JWT for sessions (2016)

#248

Post by zandl »

mdavidn wrote: post #247
zandl wrote: post #199

Earlier quoted context omitted.

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

I'm confused by your comment. Session stores seem like the easiest storage to scale horizontally. The workload is just a distributed hash, _maybe_ with atomic updates. "Three nines" durability over one day is perfectly acceptable. Use a consistent hash ring, no replication, and add nodes until you achieve the performance required.

It’s easier if you have one lookup key for a session, but often that’s not sufficient, consider the case of termination of a session by email address or by a session id. The other issue is you still have every service making high rates of network calls that require low latency since they’re often inline with the UX. So you’re relying more on a chain of IO between services which is nearly impossible to performance troubleshoot with today’s tooling.

Re: Stop using JWT for sessions (2016)

#249

Post by Ari_Ugwu »

cbsmith wrote: post #168
ale_jrb wrote: post #155

Earlier quoted context omitted.

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.

The bloom filter allows you to largely distribute the work of the server, and serves as a reasonable proxy during a failure off the server. More importantly though, there's no reason it need be a centralized server. Invalidated tokens could be broadcast to a wide number of servers that each maintain the invalidated token list (it's a great case for a CRDT, since it is append only with a TTL). Normally it'd be a prett…

Thank you for this. While I love a good old nerd round of 'stump the wizard' I also appreciate someone pumping the breaks with some realism.

Some security conversations get to the point where it's stringing together a highly unlikely chain of scenarios requiring multiple pivots, multiple concurrent failures (stochastic or otherwise), and a state sponsored actor in order to slap a 'do not use' recommendation on something.

If companies like Nike can run _Magento_ and educational sites still require Flash then I can use JWTs. Maybe...

Re: Stop using JWT for sessions (2016)

#250

Post by rusk »

0xffff2 wrote: post #228
rusk wrote: post #125

Earlier quoted context omitted.

Oh I'm not aware of the means of using JWT you describe. I think the context of this article is using JWT exclusively, and by the looks of things plenty of people are doing just that.

The article specifically addresses the confusion that you're exhibiting: >A lot of people mistakenly try to compare "cookies vs. JWT". This comparison makes no sense at all, and it's comparing apples to oranges - cookies are a storage mechanism, whereas JWT tokens are cryptographically signed tokens. There's no such thing as "JWT exclusively". The JWT is just a chunk of data; it has to be stored somewhere, either in…

I’m not too sure what you’re talking about but the article is about this confusion.
Post reply on HN