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

171–180 of 255 posts

Re: Stop using JWT for sessions (2016)

#171

Post by cryptica »

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?

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 system once in their career and now nothing will change their minds about JWTs.

Maybe JWTs don't make as much sense for HTTP but for WebSockets they are absolutely crucial. With WebSockets for example, you can push the JWTs to the clients so you can make them with very short expiry: e.g. even 10 minute expiry is possible... Issuing/renewing JWTs with very short expiry helps avoid the need to explicitly invalidate them... If used correctly, JWTs can take a lot of load off from the database.

I could go on for a long time about the benefits of JWTs with WebSockets but to summarize the best aspect for me is that you can push them to the client with short expiry and also that you can automatically renew/re-issue them on an interval while the connection is alive... It also works well for dealing with socket reconnects and saves database lookups.

Re: Stop using JWT for sessions (2016)

#172

Post by KirinDave »

weego wrote: post #159
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…

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.

I wish this were true, but I've seen JWT deployed at some large shops with terrible technical and security outcomes and everyone seems baffled how a spec could be bad. It's unfortunate.

P.S., while unrelated to my technical argument, please see my postscript above.

Re: Stop using JWT for sessions (2016)

#173

Post by kbenson »

ale_jrb wrote: post #169
kbenson wrote: post #158

Earlier quoted context omitted.

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

You don't have to kick them off. You can make it a trigger to just check whether their session has been invalidated. Store last password change date or something similar, and if the db user is still valid and the password date is older than the JWT creation date, just update the JWT and let them continue. If not, require a new login procedure or deny outright, depending on account status.

> every time someone changes their password—which should certainly invalidate their old tokens

Using a variation of above, you can just reverify the JWT every X minutes, and know that if you change a password for normal reasons all JWT tokens will be invalidated within X minutes.

It's a trade off. If you can live with what you're trading (or at least live with it after mitigations are put in place), it might be worth it.

Re: Stop using JWT for sessions (2016)

#174

Post by anon1252 »

manigandham wrote: post #105
anon1252 wrote: post #102

Earlier quoted context omitted.

> Cookies are special headers added to HTTP requests to store state. The topic is more about session VS JWT, not cookies vs whatever local storage is used in place of cookies.

"Session" does not mean anything. It is state, usually stored and sent in cookies, but just as easily stored and sent as JWTs/Auth.

Yes it does mean something. a session is something that is identified by an ID on the client and is persisted on the server with the corresponding ID. It's a concept. It doesn't have to be stored in a cookie. A session can be represented by a token and stored in any client side storage.

Re: Stop using JWT for sessions (2016)

#175

Post by enraged_camel »

kbenson wrote: post #151
drinchev wrote: post #51

Earlier quoted context omitted.

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

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

So if a single user's token gets compromised, you force ALL users to log in again?

Re: Stop using JWT for sessions (2016)

#176

Post by the_af »

davidwparker wrote: post #144
drinchev wrote: post #51

Earlier quoted context omitted.

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=" "`?

Why are checking against the DB here? Parent said a constant. You'd just check the constant value within the JWT vs the constant on the backend, and update the backend constant to invalidate.

(Correct me if I misunderstand you)

If you check against a single constant in the backend, are you invalidating all JWTs for all users whenever you want to invalidate only one? Even if you keep a blacklist of invalidated JWTs, how do you keep it up to date? How do you distribute it? What happens if the blacklist becomes unavailable for whatever reasons?

Re: Stop using JWT for sessions (2016)

#177

Post by enraged_camel »

AndrewSChapman wrote: post #133

I'm not 100% sold. I think JWT's are fine in some situations as long as you know the limitations. Regarding session invalidation, I would handle this in two ways. 1. Support a "Log everyone out" function by storing a simple version number in the JWT. If the version constant in your app is different to the number in the JWT, it is invalid. 2. Support a "I need to logout user X function" by storing a blacklist of token…

>>2. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS.

Again though, the whole point of JWT is to completely avoid server-side state management. The moment you store state somewhere (whether a list of valid tokens or a shorter list of invalid tokens) you have re-invented the concept of sessions, so why not use that instead?

Re: Stop using JWT for sessions (2016)

#178

Post by manigandham »

anon1252 wrote: post #174
manigandham wrote: post #105

Earlier quoted context omitted.

"Session" does not mean anything. It is state, usually stored and sent in cookies, but just as easily stored and sent as JWTs/Auth.

Yes it does mean something. a session is something that is identified by an ID on the client and is persisted on the server with the corresponding ID. It's a concept. It doesn't have to be stored in a cookie. A session can be represented by a token and stored in any client side storage.

Ok, yes, session is a concept. Session state can be stored in its entirety or split between an ID and body.

You can send it all to the client or you can send just an ID and lookup the body on the server.

You can send it to the client via the cookie header or via the Authorization header or something else.

You can encode the data (sent via cookies or auth header) as a JWT or your own encryption scheme.

These are all different technologies working at different layers, which is why comparing JWTs vs cookies vs sessions doesn't really make sense.

Re: Stop using JWT for sessions (2016)

#179

Post by CiPHPerCoder »

cryptica wrote: post #171
abledon wrote: post #68

Earlier quoted context omitted.

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

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. arguments) often unfold with these people.

Why are these arguments poor? In what sense does "JWT instead of server-side storage" make a better engineering decision?

> The real reason for these articles I think is that some developers had a very traumatic experience with poorly implemented JWT authentication system once in their life and now nothing will convince them otherwise.

Your ad hominem straw man argument notwithstanding, there are two orthogonal arguments that JWT defenders seem to conflate:

  1. Don't misuse JWT in places it wasn't designed for.
You can agree with one without agreeing with the other.

> Maybe JWTs don't make as. much sense for HTTP but for WebSockets they are absolitely crucial.

Would PASETO be a better fit than JWT for your envisioned WebSockets use case?

https://github.com/paragonie/paseto/tree/master/docs

Re: Stop using JWT for sessions (2016)

#180

Post by kbenson »

enraged_camel wrote: post #175
kbenson wrote: post #151

Earlier quoted context omitted.

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

>>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. So if a single user's token gets compromised, you force ALL users to log in again?

No, you force the JWT to be verified against the DB, which might be as simple as checking if the JWT creation time is older than the password update time in the DB, and if so, force only those users to log in.

All the token does is force some extra level of scrutiny. It doesn't mean the JWT has to be invalidated,but it does give you the ability to selectively invalidate specific ones for the cost of extra DB load once for all affected users.

Post reply on HN