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

71–80 of 153 posts

Re: Don't use JSON web tokens for sessions

#71

Post by jondubois »

JWT makes access control super easy/efficient in some cases because you can setup middleware functions to block/allow specific connections/requests just by looking at access rights stored in the JWT token (no need to do database lookups in many cases).

I disagree about using cookies instead of localStorage. Cookies with the HttpOnly flag enabled (as suggested in the article) don't work well in some environments such as hybrid HTML5/native apps (using WebViews) because of cross-origin restrictions - For an app which runs inside a WebView, the cookie will not be sent to the server if your script files are served from the mobile devices' file system - So your server will never get the JWT token in this case. With localStorage (or a Cookie WITHOUT HttpOnly), you can manually read the JWT using JavaScript and send it through - I know this opens you up to XSS attacks but it's a small price to pay.

Most frontend developers accept the fact that if you have malicious third-party code running inside your app's frontend, that's pretty bad news in any case. The fact that the malicious code can access a user's JWT token isn't the worst thing that could happen - At that point, the malicious frontend code could theoretically do anything it wants with your account by hijacking your UI.

The simple solution to mitigate XSS attacks is to serve all your frontend scripts from your own trusted CDNs - When it comes to vulnerabilities, there is always a tradeoff between CSRF and XSS - Personally, I find XSS threats much easier to manage than CSRF (it's a smaller attack surface).

Also, you CAN invalidate JWT tokens - You can change the auth key from the server-side (thereby invalidating the signature of previously issued tokens). Or you can send JWTs with really short expiries (e.g. every 10 minutes) and then renew them on an interval (e.g. every 9 minutes) so that the JWT doesn't expire while the user is still active.

There are a lot of different ways to use JWTs safely. It is not right for someone to say that a technology is bad unless they are aware of all the possible use cases for it.

Re: Don't use JSON web tokens for sessions

#72

Post by mwpmaybe »

jupenur wrote: post #57
SCHiM wrote: post #36

Earlier quoted context omitted.

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.

CSP isn't a silver bullet.

Re: Don't use JSON web tokens for sessions

#73

Post by Johnie »

lynndylanhurley wrote: post #69
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 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. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

Can't you maintain session state in a Redis daemon and invalidate it there? Or are you talking about stateless JWT?

Re: Don't use JSON web tokens for sessions

#74

Post by meowface »

JWTs do have plenty of valid uses.

I definitely agree with this point, though:

>If you are concerned about somebody intercepting your [anything], you should just be using TLS instead

It's weird to see a lot of devs try to reinvent the wheel and do some kind of half-assed transport encryption when they could just use TLS.

Re: Don't use JSON web tokens for sessions

#75

Post by ponyous »

mwpmaybe wrote: post #65
merb wrote: post #64

Earlier quoted context omitted.

one way would be: - generate the salt - generate the jwt - use the header base64 string as the key for your database - store the salt with the header base64 as the key in your database maybe? just one idea, basically when you are > 100.000 users you barely invalidate a single token. mostly you would kill of your secret which will invalidate any token anyway. but there are numerous ways of doing so. Edit: to the poste…

Invalidating the site secret is my go-to strategy right now, but I have wondered how to sign out a single user across all their logged-in devices. Anyway, this idea is interesting and would be pretty straightforward to implement. Thanks!

Maybe you could salt the secret per user and store it in the DB. This would allow users to have a feature like "Logout from all devices". I am not sure how you would query the database to get the salt? JWT as key and salt as value? Or maybe sending userId with each request?

Anyone know any good articles I can read on the topic?

Re: Don't use JSON web tokens for sessions

#76

Post by tym0 »

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…

Wait. You have individual salt for each user that you store in your DB?

Re: Don't use JSON web tokens for sessions

#77

Post by DelaneyM »

lynndylanhurley wrote: post #69
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 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. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

You include the time created in the object before signing, and invalidate based on that as a timeout.

Re: Don't use JSON web tokens for sessions

#80

Post by tptacek »

SCHiM wrote: post #67
merb wrote: post #60

Earlier quoted context omitted.

if you are vulnerable to XSS your HttpOnly cookie won't help you.

You are wrong. It does. It keeps your user's session from being trivially stolen. In practise this makes successfully executing attacks harder. It's not a _nice_ thing to have, it's essential. An example of this is an application that asks you to confirm after a POST or w/e. If your XSS vector is not in the new page, then you can't execute as an attacker automatically. Many, many, applications (not only on the web) i…

It does not. It is the difference between an exploit that yields a root password and one that yields a shell at uid=0.

HttpOnly is almost totally cosmetic.

Post reply on HN