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

81–90 of 255 posts

Re: Stop using JWT for sessions (2016)

#81

Post by ThePhysicist »

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…

If you assume that token invalidation happens infrequently it can still be easier to create a communication channel from individual clients/services to the authentication API through which they receive revocation requests/lists than to check every access token explicitly using a combination of API requests and caching (which also introduces invalidation delay). I'd say it really depends on how many requests per second you need to serve, how your architecture looks and how often you have to invalidate tokens.

I can definitely see the appeal of JWT tokens for infrastructures with many decentralized services and a very high request load, even when taking into account the added complexity due to invalidation issues.

Re: Stop using JWT for sessions (2016)

#82

Post by rusk »

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?

Having recently joined a project that uses JWT (I was completely ignorant of it beforehand - cookies all the way), I can say that a key advantage is convenience for developers and testing. Once you have the secret for signing you can pretty much access any of the application without having to jimmy the access-controls. I guess that could be a weakness too, but in my experience in fast moving commercially driven environments with little technical oversight (a lot of the industry these days) developer convenience does seem to drive a lot of design choices ...

Re: Stop using JWT for sessions (2016)

#83

Post by the_af »

nbevans wrote: post #75
the_af wrote: post #62

Earlier quoted context omitted.

I think by payload they mean the JWT can "store" actual permissions. Not state such as a shopping cart, but a payload composed of permissions granted to this client to do this or that in this app.

Storing security claims i.e. permissions in the JWT token is a valid use. This isn't session state. Those permissions don't change, they are in fact cryptographically immutable, until the next renewal of the token. Whereas by definition "state" does change.

I know it's a valid use (I use JWTs!). But it is state, which is why you have a payload and not merely an id. State doesn't have to change; that's mutable state. (Permissions do change, by the way, only less frequently than a shopping cart!).

Re: Stop using JWT for sessions (2016)

#84

Post by tptacek »

jehlakj wrote: post #71
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…

Invalidation isn’t hard to do at all. Simply check every half an hour or so. It does slightly undermine the benefit if using jwt tokens, but it’s better than checking against a server for each request. This is why it usually takes some websites 30-60min to completely revoke your password. This may be a concern for highly secure apps, but for most apps I think this will suffice.

Every auditor in the world checks to make sure password changes invalidate sessions, and every company with a security team will balk at that finding in a report; it would make your team look like they didn't know what they were doing. No, this isn't a norm.

Re: Stop using JWT for sessions (2016)

#86

Post by the_af »

SiempreViernes wrote: post #79
dperfect wrote: post #50

Earlier quoted context omitted.

I don’t think of JWT as a replacement for db lookups or storage, but they do provide a convenience in not having to store and manage all sessions in the database[1]. I’ve done it both ways, and as long as you’re careful about a few of the potential security issues with JWT (solve it once, put it in a reusable module), it actually does save a considerable amount of code and complexity on the server side. Also, in my c…

The author is pretty clearly comparing using jwts with using some framework provided session solution, not having you implement sessions from scratch. So just use a session library with expiration implemented, don’t take one without and add it on yourself.

Exactly! Because if you're implementing everything from scratch, you'd have to check the JWT's expiration yourself... it won't automatically expire by itself otherwise.

Re: Stop using JWT for sessions (2016)

#87

Post by gammateam »

zhobbs wrote: post #19
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.

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.

Re: Stop using JWT for sessions (2016)

#88

Post by tptacek »

vegardx wrote: post #61
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…

The reality is that hardly anything needs to be instant. You're powerless in the time period that you're setting. You don't need to have Reddit-scale traffic to have to consider this, but when you deal with a lot of backend systems it can reduce complexity a lot.

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.

Re: Stop using JWT for sessions (2016)

#89

Post by captn3m0 »

arendtio wrote: post #60

> Unless you work on a Reddit-scale application, there's no reason to be using JWT tokens as a session mechanism. And what should I use when I do work on a Reddit-scale application?

https://paseto.io/

>>Paseto is everything you love about JOSE (JWT, JWE, JWS) without any of the many design deficits that plague the JOSE standards.

Re: Stop using JWT for sessions (2016)

#90

Post by indeyets »

nine_k wrote: post #69
indeyets wrote: post #29

It's an interesting reading (together with second part), but should be taken with a grain of salt. Stateless sessions are useful under load and not necessarily under reddit-size load. I like 2-layered setup actually with long-expiration (1 year) "session" cookie kept on `auth.example.com` domain and short-lived (1 hour) JWT-cookie kept on `example.com` domain. JWT can optionally include permission for dangerous opera…

I generally agree, but to me "short-lived" would be below a minute. The point of the short-lived token is to make many clustered requests (as when a page loads a lot of assets) cheap because you only need to check a token. Any other human interaction, which takes longer, should go through the server-persisted session logic.

hi ;)

I guess that depends on exact use-cases. Below-a-minute is fine for tightly controlled environments, but publicly-used web-apps usually have a sweet spot with TTLs between 10 and 60 minutes. More requests = shorter TTL, less requests = longer ttl (as it would be counter-productive to have more auth-requests than data-requests)

Post reply on HN