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

Don't use JSON web tokens for sessions

cryto.net

Post reply on HN
Print view View original

51–60 of 153 posts

Re: Don't use JSON web tokens for sessions

#51

Post by vladgur »

Ill chime in with my $0.02

* Inability to invalidate stateless JWT tokens can be more or less be remedied with a short expiration time of the token and a token refresh flow. If a token is only valid for 5 minutes, and you can only refresh the token during that 5 minute window, it greatly reduces the attack vector. If that risk is too high, you should easily implement state with the same Redis setup that author mentions

* a classic CSRF example where youre logged into your app in one tab and you open a malicious link in another tab is not a threat if you, like the author suggests, use cookies for storage, but not for authentication. If you pass a token around in an "Authentication" header and have the server IGNORE the cookie which will inadvertently be sent, the request made in another tab via a malicious website is not going to be authenticated.

There are definite Usability and security pros to using Session cookies for storage:

* Unlike Session Storage, the cookies are visible by your application if you have two instances of it running in different tabs/windows.

* Unlike Local Storage, session cookies get wiped out when the user closes their browser

Re: Don't use JSON web tokens for sessions

#52

Post by numbsafari »

merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

Your first point is mostly dead on. I see a number of people stating that you cannot revoke a token, and it's simply not true.

The approach I use is to replace the shared session store (which is large, grows linearly with your user base, and hard to sync across clusters if you need that) with a shared revocation list.

The revocation list is small, easy to check, only contains IDs and a TTL, much less cumbersome to replicate... And is functionally equivalent.

If you have already gone the route of using a token for your session, it's really easy to implement and scales much better than a massive in memory store.

Re: Don't use JSON web tokens for sessions

#53

Post by mwpmaybe »

bjt wrote: post #41
fabian2k wrote: post #21

The one thing that I found scary when reading up on JWTs is that there is no way to revoke them. Of course you could check them against a list of revoked tokens on your server, but then your lose the stateless aspect. So the only remaining option to revoke a JWT is the nuclear option, invalidating all JWTs at once. This seemed like a rather large limitation to me. Related to this, the ability to encode further inform…

JWTs can be revoked if you sign them with application_key + some_user_revocation_string. This is how password reset tokens work in Django, for example. They're signed with the app's secret key + the user's existing password hash. Once the user uses the token to change the password, the token is no longer valid.

Hrrm, now you're in a situation where you're using part of the unverified payload to look up part of the secret before validating the signature and hence the payload. This is a neat idea but it introduces a whole class of potential vulnerabilities. (This is similar to the argument against the algorithm being selected from the unverified payload before being used to validate the signature per the JWT specification.)

Re: Don't use JSON web tokens for sessions

#54

Post by NathanKP »

merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

   You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it.
Exactly. Each JWT I generate has a salt inside which I store in the DB, and ideally the salt has accompanying data such as the datetime the JWT was generated, the IP address that generated it, etc. Now you can provide an interface that lists "sessions" and allows the invalidation of logged in sessions by deleting the salt from the DB, rendering the JWT invalid.

Re: Don't use JSON web tokens for sessions

#55

Post by merb »

numbsafari wrote: post #52
merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

Your first point is mostly dead on. I see a number of people stating that you cannot revoke a token, and it's simply not true. The approach I use is to replace the shared session store (which is large, grows linearly with your user base, and hard to sync across clusters if you need that) with a shared revocation list. The revocation list is small, easy to check, only contains IDs and a TTL, much less cumbersome to re…

actually I often see stating that you should rely on a 3rd party authentication library since its mostly well known and well tested. While I would agree here I know that mostly the library will be your weak point since you have no idea how its implemented or whenever a new version comes around if it maybe has a security issue or if you keep your version if your vulnerable to something.

Actually most people should take their authentication mechanism as something really really important and not just rely on something. It's really important that your authentication/authorization stuff works and is hardened, not just for you, also for your users. I know that auth could be really hard, especially when the language of your choice contains some bugs, but its a nogo to just use something when it is that important. I don't mean that you can't use a library, but if you do please double check the code twice on each version.

Re: Don't use JSON web tokens for sessions

#56

Post by mwpmaybe »

numbsafari wrote: post #50
ZoFreX wrote: post #38

Earlier quoted context omitted.

Your architecture being microservices doesn't change the problems with using JWTs (or any "session" system based on signing things): you can't revoke them. I am pretty confident being unable to revoke tokens will start to be a problem with any sufficiently large websites: you don't just need to scale in terms of traffic, but also in terms of people doing bad things. If you're at this sort of scale, adding in another…

You can (and should) use a revocation list. This is really no different than doing invalidation/revocation of stored sessions because you have the same job of sending the session/token ID out to all dependencies. But, instead of keeping a giant memory store of all sessions in sync across clusters, you only have to keep a short lived list of revoked tokens. Less noise, less memory, same difference.

What does the revocation list look like? "Reject all tokens for user X issued before timestamp Y?" Or do you assign UUIDs to your tokens?

Re: Don't use JSON web tokens for sessions

#57

Post by jupenur »

SCHiM wrote: post #36
chrisfosterelli wrote: post #20

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around t…

I've tested many web applications, and around 80% of all applications I've tested contained an XSS of some sort or another, that number drops to around 40% if you only look at stored XSS & XSS in a get request. And to less than 10% when only looking at stored XSS. Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing. Do NOT store sessions in anything other than cookies with th…

> Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing

Then again you could just use CSP and mitigate almost 100% of those XSS cases. Yes, even most of the stored ones. And with JWT + JavaScript you don't have to worry about all the oddities in the way cookies work, which is a huge plus.

Re: Don't use JSON web tokens for sessions

#58

Post by mwpmaybe »

NathanKP wrote: post #54
merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. Exactly. Each JWT I generate has a salt inside which I store in the DB, and ideally the salt has accompanying data such as the datetime the JWT was generated, the IP address that generated it, etc. Now you can provide an interface that lists "sessions" and allows the invalidation of logged in sess…

I asked this question below, but how do you use the payload to select the correct salt from the database in order to verify the signature before verifying the signature and confirming that the payload is valid?

Re: Don't use JSON web tokens for sessions

#59

Post by rahkiin »

Kiro wrote: post #10
rahkiin wrote: post #6

Earlier quoted context omitted.

You would do it by adding a Redis server that stores stateful sessions (mentioned in the article). I however disagree with most of the points made in the article, and use stateless JWT myself.

Wouldn't that violate the RESTfulness? I thought stateless was one of the criterias.

Yeah, I guess it is. I only use redis for a simple cache and for worker queues. For authentication I use JWT. I store the user permissions inside the token, purely to be used by the client side (for showing/hiding interface elements). Permissions in the backend are over the database. So I tried to minimize the revoke-problem.

Re: Don't use JSON web tokens for sessions

#60

Post by merb »

SCHiM wrote: post #36
chrisfosterelli wrote: post #20

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around t…

I've tested many web applications, and around 80% of all applications I've tested contained an XSS of some sort or another, that number drops to around 40% if you only look at stored XSS & XSS in a get request. And to less than 10% when only looking at stored XSS. Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing. Do NOT store sessions in anything other than cookies with th…

if you are vulnerable to XSS your HttpOnly cookie won't help you.
Post reply on HN