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

151–160 of 255 posts

Re: Stop using JWT for sessions (2016)

#151

Post by kbenson »

drinchev wrote: post #51
tehlike wrote: post #14

Earlier quoted context omitted.

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

What's the point of having a token if you need to check it with a database on every request? Instead of `SELECT isValid from tokens where token=" "`, why not `SELECT user from sessions where session=" "`?

You don't store the token in the database, you put it in a channel that deploys with your app and can up updated as needed. That can be a flat file shipped with production, or if a production push is too costly, set some other way.

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. It's a manual fail-safe to invalidate stored sessions.

This, of course can spike load considerably in the period immediately after, so if that's a problem, you can always use multiple tokens based on some criteria, such as one matching the first letter of the username, or the user id mod some value, so split your user into N chunks that each have their own invalidation token, so you only have to invalidate the sessions of 1/N users.

Re: Stop using JWT for sessions (2016)

#152

Post by manigandham »

CiPHPerCoder wrote: post #128
manigandham wrote: post #124

Earlier quoted context omitted.

The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works. If you want to say that client sessions should not be 100% on the client side and should be split between client/server then just say that. There are pros/cons but at least that is a clear argument instead of misleading about JWTs.

> The basis of that entire argument is based on a false understanding of what JWTs are and how HTTP state transfer works. I don't even see why you believe this to be the case. The article (and the follow-up) are both pretty clear about what the actual issue is. Did you read them or just react to the headline?

It seems you are overly defensive about an article that you agree in other comments is "not about JWTs" even though it is titled as such and talks about them at great length.

I think you can also see from my other comments that I know what I'm talking about and my issue is the fact that * instead of discussing client/stateless vs client/server shared state*, this article spreads more misleading information about JWTs and sessions.

Re: Stop using JWT for sessions (2016)

#153

Post by merlincorey »

gammateam wrote: post #87
zhobbs wrote: post #19

Earlier quoted context omitted.

With this method isn't the downside that you have to invalidate all tokens, and not just the attacker's tokens?

which isn't bad because all the processing is done client side anyway.

> which isn't bad because all the processing is done client side anyway.

I believe people are downvoting you because you may have overlooked the processing that must happen on the server to encode the token in the first place.

Re: Stop using JWT for sessions (2016)

#154

Post by Exuma »

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)?

Re: Stop using JWT for sessions (2016)

#155

Post by ale_jrb »

xae342 wrote: post #136
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 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.

Re: Stop using JWT for sessions (2016)

#156

Post by aaaaaaaaaab »

nbevans wrote: post #55
drinchev wrote: post #9

Earlier quoted context omitted.

What about a stolen user password and an actor, who already uses your token? Can the targeted user kick him out by resetting his / her password?

Sure why not? Each user account has a counter or timestamp on it in the user registry. If the JWT token in the request passes crypto validation but it has an older counter/timestamp than held in the user registry then it is deemed invalid and the user must re-authenticate. This is still a horizontally scalable design.

This “user registry” of yours sounds an awful lot like a traditional session table in a central DB.

Could you elaborate a bit on that in terms of horizontal scalability please?

Re: Stop using JWT for sessions (2016)

#157

Post by zimpenfish »

tebruno99 wrote: post #123

"You cannot invalidate individual JWT tokens" This is not exactly true. There are lots of things you can do to expire tokens. For instance, every JWT has a creation date stamp so you could say on the server side all tokens created before Time.Now() no longer accept as valid. Allowing users to expire ALL tokens, etc.

> you could say on the server side all tokens created before Time.Now() no longer accept as valid

But that's not anywhere near "invalidate individual JWT tokens" - you're invalidating -every- token before `Time.Now()`. Unless you store a different "valid after" time per user and then you're back to storing sessions in the DB, aren't you?

Re: Stop using JWT for sessions (2016)

#158

Post by kbenson »

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 manually set), which when it changes forces a re-auth (either just a DB auth session because you've specifically set the conditions such that you only care if PW changed or some other flag set, or a full login procedure).

If the same static token is used for all users, all users will need to do this on the next request. If you subdivide your users by some metric (first x characters of username, some modulo of numeric ID) then you can invalidate some subset of the userbase JWT tokens instead.

You've now gained the ability to immediately invalidate a JWT tokens as long as you're okay with forcing extra computation on some larger set of completely valid ones at the same time.

Edit: Changed wording of last sentence to clarify you don't necessarily have to invalidate all sessions just by invalidating all JWT tokens, as outlined in further comments below.

Re: Stop using JWT for sessions (2016)

#159

Post by weego »

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…

Ultimately the reason JWT works for people regardless of these flaws is that almost no one ever uses it in an environment where it scales past the point that something like a blacklist lookup is a crippling flaw in the infrastructure.

Re: Stop using JWT for sessions (2016)

#160

Post by jopsen »

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

Post reply on HN