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

161–170 of 255 posts

Re: Stop using JWT for sessions (2016)

#161

Post by EpicEng »

tehlike wrote: post #14
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…

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

In which case you wouldn't use JWT tokens at all...

Re: Stop using JWT for sessions (2016)

#162

Post by bradstewart »

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

Re: Stop using JWT for sessions (2016)

#163

Post by zerkten »

vegardx wrote: post #113
tptacek wrote: post #88

Earlier quoted context omitted.

Isn't this like the one component of an application design where you really do need it to be instant? People get confused because invalidation doesn't happen often. But you also don't use a fire extinguisher often, and you get those checked all the time to... wait, bad example.

I guess that depends on the application. So long as you can guarantee that it happens within a given time frame that might very well be good enough. That said, I don't think a lot of people really take this into consideration when they use a stateless JWTs, or the computation required to issue really short lived tokens. Aaaand now I have to check my fire extinguisher.

> I guess that depends on the application. So long as you can guarantee that it happens within a given time frame that might very well be good enough.

I think the right answer is that you need to develop some type of threat models, review them periodically, and then decide what's right. Just because you can't think of a problem with the approach now doesn't mean it won't happen later, or be a component of a larger attack. The "given time frame" above may be more than enough for certain attacks you can identify in initial threat modeling.

From the long-term operational perspective, it may also be preferable for the application owner to have immediate invalidation. This might be inconvenient to the development team just trying to get their work done now, but is it a good idea to ignore this requirement? For various reasons, dev teams tend to push on only for there to be problems later.

Re: Stop using JWT for sessions (2016)

#164

Post by [deleted] »

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?

[deleted]

Re: Stop using JWT for sessions (2016)

#165

Post by CiPHPerCoder »

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

The alternative to JWTs isn't rolling your own signing scheme. Use PASETO instead. https://paseto.io

But the issue being discussed in this article is about how JWTs are being used, not JWTs themselves.

> don't do security if you don't understand your primitives..

The security industry needs to do more to provide tools that do security for people who don't understand their primitives.

Re: Stop using JWT for sessions (2016)

#166

Post by [deleted] »

intothemild wrote: post #77
abledon wrote: post #68

Earlier quoted context omitted.

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

Because front-end engineers always fall for whatever cult is hyped right now. They usually don’t understand the issues around the things they want to build, they do it because it’s cool and new, and don’t stop to ask or research anything.

[deleted]

Re: Stop using JWT for sessions (2016)

#167

Post by tschellenbach »

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?

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.

Re: Stop using JWT for sessions (2016)

#168

Post by cbsmith »

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.

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 pretty compact list, and if it isn't, you probably want to take a more defensive posture anyway.

...and beyond that, if an attacker can take out your invalidation server, which needn't be directly accessible to the public, you've already had a pretty serious security breech. I think the least of your problems would be the invalidation server.

Re: Stop using JWT for sessions (2016)

#169

Post by ale_jrb »

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…

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.

Re: Stop using JWT for sessions (2016)

#170

Post by dpark »

caiob wrote: post #145
dpark wrote: post #92

Earlier quoted context omitted.

No. The discussion here is about using JWT for sessions with web clients. If you’re registering a dedicated client id and secret for each web client, they you’re doing something wrong. If you’re doing this and then also using JWT, then you’re doing something really bizarre, and still wrong. Id/secret pairs can make lots of sense for integrating partner services with your API. They make no sense for web clients, where…

Classic hostility on HN. I'm out, I'll go find my tribe.

Nowhere was I hostile. I answered your comments politely and clearly. You were arrogant and condescending but you apparently don't actually know what you're talking about.

Please do go find your tribe of condescending devs with fragile egos.

Post reply on HN