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

211–220 of 255 posts

Re: Stop using JWT for sessions (2016)

#211

Post by marcosdumay »

kbenson wrote: post #158
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…

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

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?

Re: Stop using JWT for sessions (2016)

#212

Post by foxhill »

KirinDave wrote: post #143
mgraczyk wrote: post #117

Like many other articles on JWTs, this one mischaracterizes the trade-offs that exist. You can invalidate individual JWTs, you simply store the blacklisted token IDs in a table in your database. Implemented naively, this results in a request flow in which the database is still accessed on every request, defeating one primary purpose for using JWTs. However, there are better ways. Since the blacklist is just a collect…

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

> not only is the phrase "black" list steeped in a history you may not realize you're invoking

nonsense.

> but it's much less precise than the term "stop list"

tenuous. the term blacklist has existed since at least the 1600s[1]. i would be surprised if its meaning was not well understood.

[1] - https://en.wikipedia.org/wiki/Blacklisting

Re: Stop using JWT for sessions (2016)

#213

Post by m4n »

Alex3917 wrote: post #209
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…

> This means that you cannot, for example, invalidate the session of an attacker after detecting a compromise. You also cannot invalidate old sessions when a user changes their password. Sure you can. Just have a 'date_password_last_changed' field on your user model, and compare that with the issued_at date on the jwt. Since your user model presumably gets retrieved for each authenticated request anyway, there are ze…

Updating the 'date_password_last_changed' will invalidate all the tokens for a user. It solves the purpose but has its own trade offs.

Re: Stop using JWT for sessions (2016)

#214

Post by dvlsg »

jjeaff wrote: post #206
detaro wrote: post #181

Earlier quoted context omitted.

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

Probably just because web sockets tend to be used for frequent updates and jwt allows you to authenticate a user without necessarily pinging your sessions table on every single call.

Do you have to ping auth on every websocket communication? I feel like you should be able to auth once when you open the connection, and then keep track of the intended session timeout locally (unless you expect external factors to extend that timeout I suppose).

Unless that's in regards to checking whether an auth has been blacklisted, which isn't something jwt solves, as far as I can tell.

Re: Stop using JWT for sessions (2016)

#215

Post by mgraczyk »

KirinDave wrote: post #143
mgraczyk wrote: post #117

Like many other articles on JWTs, this one mischaracterizes the trade-offs that exist. You can invalidate individual JWTs, you simply store the blacklisted token IDs in a table in your database. Implemented naively, this results in a request flow in which the database is still accessed on every request, defeating one primary purpose for using JWTs. However, there are better ways. Since the blacklist is just a collect…

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

Re: Stop using JWT for sessions (2016)

#216

Post by anon1252 »

jopsen wrote: post #160

Wow, I wish people would stop complaining about JWTs.. JWTs are a silver bullet, but it's nicer than rolling your own signing scheme. Don't run with scissors, don't do security if you don't understand your primitives..

> JWTs are a silver bullet, but it's nicer than rolling your own signing scheme.

you can use HMAC to sign session cookies as well, the issue isn't about signing.

Re: Stop using JWT for sessions (2016)

#217

Post by Exuma »

bradstewart wrote: post #162
Exuma wrote: post #154

Can someone explain how this is similar/different from the default ways Ruby on Rails stores sessions? I know they're encrypted and signed, and all the session data is stored in the cookie. This seems to work great, what is the downside of just doing this method (for say, bigger sites)?

The only downside I've ever encountered to Rails default sessions involves authenticating against other backend endpoints from JS applications served by Rails. Which really has very little to do with Rails itself...

So do you know the difference between that way and the JWT way? All these different methods are kind of confusing, and it seems Rails does it a great way, and everyone hates JWT... but arent they basically the same thing?

Re: Stop using JWT for sessions (2016)

#218

Post by the_af »

dperfect wrote: post #205
the_af wrote: post #138

Earlier quoted context omitted.

> there are valid uses cases where JWT makes sense (it isn’t categorically “bad” as the author tries to show). The author does sound negative, but doesn't claim JWTs are categorically bad; he actually mentions cases where JWTs are useful: when they are used as single-use tokens. The author claims JWTs as sessions are too problematic to be useful. > I’ve seen some pretty terrible security issues in both JWT and framew…

The "battle-tested" argument is becoming less and less obvious. As for being error-prone, I've seen a lot of people set up their session cookies incorrectly/insecurely when using traditional session tokens (and framework-provided authentication libraries), so I'd guess the two approaches are about on equal ground in the "error-prone" department.

Yes, the battle-tested argument becomes moot when enough time passes and there's enough adoption. This doesn't make the original argument invalid, though -- just unheeded! ;) It seems we software devs are doomed to reinvent the wheel, again, and again, and again.

As for session cookies: like the author says, cookies are a storage medium and orthogonal to the issue. You can have all the problems of JWTs in addition to all the problems of cookies.

Re: Stop using JWT for sessions (2016)

#219

Post by novaleaf »

How I use JWT:

an encrypted storage of the user's authentication credentials, stuffed into a persistent domain cookie.

Thus, JWT is just a standardized way of encrypting a json payload and storing/retrieving it in a cookie.

works for me (my arch is stateless), and seems orthogonal to the arguments described in the article.

Re: Stop using JWT for sessions (2016)

#220

Post by kbenson »

unclebucknasty wrote: post #207
kbenson wrote: post #190

Earlier quoted context omitted.

You can serve pages that don't require DB access without ever hitting the DB. Static content that is restricted to authed accounts is able to be served immediately and directly. Requests that access resources other then ones shared with the auth system do not need to first access the auth system to verify the account. Even if the auth system is on the same DB as the rest of the content, it's no longer a sequential bo…

Yeah, I can see scenarios where these features would be useful, but wonder how many architectures truly benefit from it? I'd guess that a good many people implement JWT b/c it's the accepted approach or in premature anticipation of a future scaled-out architecture that would land it more in one of the beneficial scenarios. Of course, if the DB concern is one of performance, then there's also a performance trade-off w…

Sure, I'm not making a case for using JWT, I'm just noting the options and capabilities that you have if you do, which I think weren't accurately expressed initially.

There are cases where JWT can make a lot of sense. For example, a high capacity API where you don't necessarily want to check auth for every request, especially if you can rely on some sort of caching infrastructure. In that case it may make sense to use JWT, re-check the authentication on some set schedule (whether once an hour or day), and save yourself what might be a few thousand authentications a minute.

Post reply on HN