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

Stop Using JWTs

gist.github.com

Post reply on HN
Print view View original

21–30 of 335 posts

Re: Stop Using JWTs

#21

Post by hparadiz »

tracker1 wrote: post #9

JWTs are insecure... even when using trusted, rsa/ppk based signing methods? not shared secrets. JWTs are too long lived... Nothing is stopping you from limiting the JWT lifetime and having a refresh model against an authentication authority... I mean, even if you use cookie based sessions, you're storing somewhere... you can have a jwt valid for 5-15min. 15minutes is roughly the cache timing for many authorization s…

You can make a JWT invalid after 30 seconds or even 1 second. You should set an aud (audience) when creating the JWT. Otherwise the signature is crypto-graphically sound. Validate every single JWT every single time with a short lifetime.

OIDC tokens are all JWTs btw.

Re: Stop Using JWTs

#22

Post by hparadiz »

jotato wrote: post #18
ApolloFortyNine wrote: post #8

This links to some other blog post for the bulk of it's 'why', and that blog post mostly seems to be annoyed about "You cannot invalidate individual JWT tokens". Which every time I've implemented, the general guideline is to check for invalidated nonces somewhere. Which resolves that random blog posts second point too. >The JWT specification itself is not trusted by security experts. This feels like it needs more evi…

> "You cannot invalidate individual JWT tokens". Which every time I've implemented, the general guideline is to check for invalidated nonces somewhere. Which resolves that random blog posts second point too. 100% agree. This is common sense to me and I'm always surprised to re-learn people don't do this

Not checking the signature on every single JWT is the same as storing a password in plain text.

Re: Stop Using JWTs

#24

Post by elcritch »

vova_hn2 wrote: post #12

One of the articles that TFA links to [0] contains the following paragraphs: > 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 detec…

It really doesn’t seem very hard to have a small invalidation list. Just a redis cache or a simple broadcaster, etc.

Does anyone have an example of how they built a JWT revocation service?

Re: Stop Using JWTs

#25

Post by hoppp »

What if I put a jwt in a session cookie?

The post is not descriptive enough

It should explain how to not store JWT instead of just saying JWT is bad.

Re: Stop Using JWTs

#26

Post by littlecranky67 »

vova_hn2 wrote: post #12

One of the articles that TFA links to [0] contains the following paragraphs: > 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 detec…

>> 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'm not sure that this is entirely true.

You can be sure it is not true, because it is utter BS. JWTs have an "iat" timestamp field (issued at) and in the described case that an attacker has a leaked token, your validation logic simply should refuse any token with iat I have JWTs implemented for a site and in my case, users cannot individually revoke tokens - but they have a "Signout from all devices" option. That will basically just set a field "minimum_issued_at" to $NOW in the database for their user, and any tokens will always be validated against the minimum iat timestamp. That is a good compromise in security and simplicity.

Revocation lists have their purpose, though, in systems with heightened security requirements.

Re: Stop Using JWTs

#27

Post by littlecranky67 »

elcritch wrote: post #24
vova_hn2 wrote: post #12

One of the articles that TFA links to [0] contains the following paragraphs: > 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 detec…

It really doesn’t seem very hard to have a small invalidation list. Just a redis cache or a simple broadcaster, etc. Does anyone have an example of how they built a JWT revocation service?

See my sibling comment about the "signout from all devices / iat" pattern. This is only a few lines of code.

If you want to be more fancy and fast, you can use bloom filters to check if a token is in a revocation list.

Re: Stop Using JWTs

#28

Post by dariosalvi78 »

szmarczak wrote: post #10

No need to stop. The XSS argument also applies when using cookies. JWTs are just tokens like session data but in JSON format. What format you choose to go with doesn't matter. You can keep storing JWTs in local storage and still be secure. Discord removes it on page load and restores it when the tab is closed. Also if your website is susceptible to XSS, skill issue, exactly like in the case of SQL injections. That wo…

with cookies you can restrict them to HttpOnly so that they are not exposed to client-side scripts. This reduces the chances of XSS to access the long-lived access tokens (JWT or session ids).

Re: Stop Using JWTs

#29

Post by vova_hn2 »

littlecranky67 wrote: post #26
vova_hn2 wrote: post #12

One of the articles that TFA links to [0] contains the following paragraphs: > 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 detec…

>> 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'm not sure that this is entirely true. You can be sure it is not true, because it is utter BS. JWTs have an "iat" timestamp field (issued at) and in the described case that an attacker has…

> your validation logic simply should refuse any token before $NOW.

Well, this approach throws out a lot of babies with the bathwater. You invalidate tons of legitimate tokens along with the one that you wanted to invalidate and get a thundering herd [0] of clients wishing to re-authenticate.

This is probably not good in case of a really high load.

And if you don't have a really high load, then there is no good reason not to have a stateful session storage.

[0] https://en.wikipedia.org/wiki/Thundering_herd_problem

Post reply on HN