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

231–240 of 255 posts

Re: Stop using JWT for sessions (2016)

#231

Post by mschuster91 »

martin-adams wrote: post #73
mschuster91 wrote: post #27

Earlier quoted context omitted.

Or, implement a "master token" scheme: have a long-lived master token, which is used only for generating short-lived (e.g. 5 min) tokens that are actually used for authentication/authorization at the API endpoint. User gets banned or privileges revoked? Fine, revoke the master token on the authentication server and after 5 minutes at the latest, the user is locked out as he cannot get new valid short-lived tokens. Se…

>> Fine, revoke the master token on the authentication server and after 5 minutes at the latest That might be fine for a lot of use cases. But anything that can steal money using that token and 5 minutes is a very long time indeed.

    But anything that can steal money using that token and 5 minutes is a very long time indeed.
Then implement a check for the token in destructive operations. Should keep the performance impact pretty low.

Re: Stop using JWT for sessions (2016)

#232

Post by unclebucknasty »

kbenson wrote: post #220
unclebucknasty wrote: post #207

Earlier quoted context omitted.

Yeah, I can see scenarios where these features would be useful, but wonder how many architectures truly benefit from it? I'd guess that a good many people implement JWT b/c it's the accepted approach or in premature anticipation of a future scaled-out architecture that would land it more in one of the beneficial scenarios. Of course, if the DB concern is one of performance, then there's also a performance trade-off w…

Sure, I'm not making a case for using JWT, I'm just noting the options and capabilities that you have if you do, which I think weren't accurately expressed initially. There are cases where JWT can make a lot of sense. For example, a high capacity API where you don't necessarily want to check auth for every request, especially if you can rely on some sort of caching infrastructure. In that case it may make sense to us…

Yeah, I always thought the API scenario was the original use case for JWT anyway and believe that it does makes more sense. I think API token expiry is a requirement too, but not as pressing or frequent as on the user-side.

With the advent of SPAs and RESTful designs, it was probably tempting to say, "hey, let's allow our user-facing client apps to hit the API directly and use the same JWT token scheme for auth there". So, whereas it was generally a good scheme for APIs, it became a YMMV thing once it diverged into the client.

Re: Stop using JWT for sessions (2016)

#233

Post by GhostVII »

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…

Couldn't you use JWT's with both an access token and a refresh token? The access token can have a fairly short expiry time, after which you hit the auth service with the refresh token, at which point you can handle any token invalidation, while still allowing most of your requests to go through just using the JWT.

Re: Stop using JWT for sessions (2016)

#234

Post by philsnow »

bearjaws wrote: post #186
kbenson wrote: post #173

Earlier quoted context omitted.

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…

We tie our users session in the JWT to the session in a central database, this allows us to invalidate individual sessions. The reason for using JWT is that the UI and backend consume the same session object seamlessly. Before what we got in our PHP session and what state we shared with the UI were manually kept in sync through a API request.

> session object

what fields are in this session object besides an identifier?

Re: Stop using JWT for sessions (2016)

#235

Post by jehlakj »

tptacek wrote: post #84
jehlakj wrote: post #71

Earlier quoted context omitted.

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.

Although I agree with the ideal behavior you mentioned, your comment about "every company with a security team" is not true. Google does this with their firebase product using a combination of long and short-lived tokens.

I simply offered a reasonable solution to revoke JWT tokens. Would I use them in a project? Probably not. Even so, if an attacker has compromised someone's session, it's probably too late.

Re: Stop using JWT for sessions (2016)

#236

Post by wheresvic1 »

jcadam wrote: post #114

I use JWT for authentication on my current project. And I eventually ended up having to check the user's 'role' in the database for authorization before I let them do anything anyway (and consequently, revoking someone's user role or suspending their account has immediate effect). I saw many examples on the net of people putting role/authorization and various other types of session information within the JWT and it j…

> I saw many examples on the net of people putting role/authorization and various other types of session information within the JWT and it just looked insane to me.

Why is this crazy? If you encrypt your JWT with a private key that is only known to the server, then any modification to the JWT will lead to an invalid token.

The only thing here is that the list of roles granted is visible to the user if they were to decode the JWT, which is something you might not be entirely comfortable with but I don't think it's totally crazy.

Re: Stop using JWT for sessions (2016)

#237

Post by csours »

drinchev wrote: post #9
csours wrote: post #7

We have a requirement that users be logged out after 30 minutes of inactivity, so JWTs are perfect for our use case.

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?

No, but that's 3 systems away upstream anyway - thus the 30 minute timeout.

Re: Stop using JWT for sessions (2016)

#238

Post by matthewaveryusa »

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…

Short TTLs on tokens can work very well depending on what the goal is.

If you're doing high-ops and your goal is to reduce authorization calls the TTL acts effectively as a cache that decouples API ops and authorization ops.

The compromise being that you can only rotate as fast as the TTL.

That is of course unless you want to implement revocation-list capabilities. But if your revocation-list server goes down you're back to the TTL limitation.

Re: Stop using JWT for sessions (2016)

#239

Post by justaaron »

detaro wrote: post #30
justaaron wrote: post #6

what about setting a secure cookie with a jwt, and expiring it when you log-out? what is the utility in server-sessions? (aside from the ability to revoke it at any time from the server.)

Do you mean "delete the cookie" with "expiring it"? Then that doesn't help against an attacker which already has obtained the JWT, they can still use the JWT until it's expiry.

what i propose: 1) login = sending username and hashed password (over tls) that does a bcrypt etc, compares to bcrypted etc hash in db, if correct = provide a jwt set as a cookie with "secure httpOnly", jwt should be logged.

2) logout = request to server, server sets cookie with "token=empty;expires:1970yaddayadda" as it's httpOnly there's no client-side messing baout with the cookie otherwise

3)_all pages send cookie with each request, so must be tls

upon logout, cookie has empty token, must be re-set with new token. old token, if stolen, can be compared with logged history, etc.

what do you see, in terms of flaws?

Re: Stop using JWT for sessions (2016)

#240

Post by justaaron »

anon1252 wrote: post #26
justaaron wrote: post #6

what about setting a secure cookie with a jwt, and expiring it when you log-out? what is the utility in server-sessions? (aside from the ability to revoke it at any time from the server.)

> and expiring it when you log-out? and how would you do that if the user doesn't actively log out of a service?

set the cookie in the response to their next request to you?

specifics depend upon the language and framework used on the server, etc...

Post reply on HN