Oh fuck off.
This energy and thinking inside the appsec community (of which i am a working member) is the reason the local _pizza company_ feels the need to have a 12 hour timeout on my mobile phone. Just implement a decent content security policy and then you can have the best of both worlds: stateless backend without having the (incredibly minor) risk of having your jwt token stole on my goddamn pizza website.
Stop using JSON Web Tokens for user sessions
21–30 of 145 posts
Re: Stop using JSON Web Tokens for user sessions
#22look at any web client based authentication system like firebase or amazon cognito from FAANG companies.
Cognito by default stores it in local storage, and firebase stores in index db and local storage.
You can switch to cookies, but it is not possible to set httponly flag because they are client based (js based).
And that's the tip of the iceberg.
Re: Stop using JSON Web Tokens for user sessions
#23It would be helpful if the post not only told you what to _not_ do (especially when it is a frequently done thing) but offered any sort of alternative.
Probably a generalization but in my experience many IT security people don't seem very pragmatic. "No you can't do that" but no alternative. "No don't use that cipher" but can't tell you the correct one. "Don't use equipment that doesn't receive firmware updates anymore and doesn't support newer encryption standards". "Don't allow mDNS" so no more printing from smartphones or presenting stuff from your laptop using Miracast? It gets tiresome really fast.
Edit: yeah sure downvote me into oblivion. I'm not throwing away perfectly functional equipment because it doesn't support the latest and greatest ciphersuite. I'm also not planning on a being a roadblock on everything, it's balancing act.
Re: Stop using JSON Web Tokens for user sessions
#24As a side question (or rather, what I expected the central point of the article to be instead): how are you supposed to actually use JWT? The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right? This means we need a short-lived access token (5 min or so?) so that sessions are revoked in a reasonable time if the token is stolen som…
Your refresh token does not need to be a JWT, it needs to be checked once in a blue moon and a server side round trip is OK
Re: Stop using JSON Web Tokens for user sessions
#25It's interesting how much of an upward hill battle it has been for me to argue that JWT tokens need to be stored in cookies rather than LocalStorage. In my latest project, the lead backend dev is convinced it is insecure to store the accessToken in a HTTPOnly cookie, and that it HAS to be stored in LocalStorage.
But aren't HTTPonly coookies stored in a SQLite db, and have no password attached in Firefox or Chrome?
Both cookies and localStorage are usually stored in an SQLite db…
localStorage is totally accessible to any JavaScript running on the page, so your session can be completely hijacked and used later.
Re: Stop using JSON Web Tokens for user sessions
#26In my opinion there are 2 good approaches: If you really need to use JWT-s then store the refresh (just normal UUID looking token that is validated on the backend) token in a httpOnly cookie and JWT in local/session storage, use 10-15 minutes expiration and you are somewhat OK on logout= (the XSS is still maybe exploitable). On logout make sure to invalidate the refresh token. In my opinion a better way is to just us…
> I would not try to cram JWT-s into cookies they are too big, but maybe these days nobody cares about the extra bytes
Why does the length matter compared to when they are sent with cookies or with a special header?
Re: Stop using JSON Web Tokens for user sessions
#27The lack of logout and XSS are problems, but I ran into a couple apps that completely forgot to expire sessions due to lacking framework support. In nodejs's cookie-session and @google-cloud/connect-firestore sessions never expire. This issue impacts downstream software including, awkwardly enough, Google's Passkey demo apps. There isn't interest in fixing this.
Make sure your app is actually using a JWT framework, not a lesser version, and implements basic security practices.
Re: Stop using JSON Web Tokens for user sessions
#28As a side question (or rather, what I expected the central point of the article to be instead): how are you supposed to actually use JWT? The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right? This means we need a short-lived access token (5 min or so?) so that sessions are revoked in a reasonable time if the token is stolen som…
Your refresh token does not need to be a JWT, it needs to be checked once in a blue moon and a server side round trip is OK
But I already pointed that out in my question. You didn't address my actual concern.
Re: Stop using JSON Web Tokens for user sessions
#29Re: Stop using JSON Web Tokens for user sessions
#30TLDR: You can split the JWT into 3 parts and store them differently in cookies to keep the _payload_ accessible in JavaScript and make the _signature_ inaccessible from the web app.
In the following Stackoverflow thread (https://stackoverflow.com/a/60941643) I described a way to store a JWT in Cookies while keeping convenient to use payload from the Javascript stack (for instance to display the user name).
This is achieved by splitting the JWT in 3 parts (header, payload and signature) and storing it into 3 different Cookies which have different properties. The _header_ and _payload_ would be accessible from the web application while the _signature_ is configured with HttpOnly and therefore unaccessible from the web app. The inconvenient of this method is that you have to reconstruct/concat the 3 parts server side.
Disclaimer: it's actually an experiment which has for purpose to get the better of both world and it has not been tested from security standpoint.