291–300 of 335 posts
Earlier quoted context omitted.
You either reissue tokens constantly, every couple minutes or so, or you have to reliably invalidate.
Maybe you do. Why would I have to do that?
Earlier quoted context omitted.
A lot of times local storage is much less secure than using cookies. Cookies have about 20 years of infra built around it (HttpOnly, SameSite, Secure, etc). There's some weird parts about cookies, but local storage really shouldn't be used for anything security sensitive
20 years of security: sqlite3 cookies.sqlite 'SELECT name, value FROM moz_cookies WHERE isSecure AND isHttpOnly' And that's a supposedly a master password protected browser. They can't even bother encrypting cookies. Don't be ridiculous.
Local storage isn't any better in this regard
Earlier quoted context omitted.
A lot of times local storage is much less secure than using cookies. Cookies have about 20 years of infra built around it (HttpOnly, SameSite, Secure, etc). There's some weird parts about cookies, but local storage really shouldn't be used for anything security sensitive
> A lot of times local storage is much less secure than using cookies. Is it? If an attacker can't do XSS then it's as strong as cookies. Supply chain attacks aren't an argument here because they can also happen with cookies. CSRF as well. The same can happen in actual executable binaries. I don't get the 20 yr age argument: - HttpOnly fights XSS which is impossible to execute with modern frontend frameworks. - SameS…
Eh. Frontend frameworks tend to make successful XSS much worse because they tend to require disabling HttpOnly for not very good reasons. HttpOnly is a nice defense in depth measure against the consequences of XSS.
> - SameSite fights CSRF but the real solution is to disable loading the website in iframes (remember clickjacking?).
Disabling iframes doesn't fix CSRF. You can still or tags or whatever. For an example, see these universal logout pages. SameSite helps with CSRF (you really should also using CSRF tokens as the primary control and maybe using the Sec-Fetch-X headers as well).
Earlier quoted context omitted.
Yes we have heard this before, React is only 30kb! But that misses the enormous amount of infra you need to even just do a basic fetch. (Read the post by the React Query author on whether you need React Query or not) Likewise with JWTs for sessions you need to handle cache invalidation, revocation lists, key rotation, the list of difficult comp sci problems really does go on! The same issue as always plaguing the fro…
> Yes we have heard this before, React is only 30kb! Not quite. You might be surprised to know, but the whole JOSE standard, and JWT in particular, specify a very limited set of fields. Whenever anyone starts requiring more than that, the responsibilities start to be offloaded to the likes of OpenID Connect.
Earlier quoted context omitted.
> if you have to check an identifier for revocation on every request you could just use an opaque session ID and look that up on every request instead! One reason could be the size. A revocation list only needs to keep session IDs of recently logged-out sessions, for which the token's TTL hasn't yet expired. It may be a much smaller list than a list of every active session. Also, a JWT (or a Macaroon, etc) can store…
Another point is that managing session data on the server-side is a pain... If your app server goes down, stale session data would be left behind in your session store; it can easily become orphaned... So you need to set an expiry on it to ensure that it will be cleaned up no matter what... But you need to keep extending the expiry while the user is still online. God forbid you create the session data before you set…
Tell me you haven’t been writing web apps for a long time without telling me. There are many ways to solve the problems you describe here, which have been put into widespread use by web frameworks serving literally billions of users stretching back decades. Why reinvent the wheel with something that wasn’t designed to be a long-lived session store in the first place?
I think the Rails default is quite clever (the entire session lives in a cookie on the client), which gets around most of the problems you specify. But there are many other approaches if that doesn’t work for your use case.
Earlier quoted context omitted.
Another point is that managing session data on the server-side is a pain... If your app server goes down, stale session data would be left behind in your session store; it can easily become orphaned... So you need to set an expiry on it to ensure that it will be cleaned up no matter what... But you need to keep extending the expiry while the user is still online. God forbid you create the session data before you set…
> Another point is that managing session data on the server-side is a pain... If your app server goes down, stale session data would be left behind in your session store; it can easily become orphaned... So you need to set an expiry on it to ensure that it will be cleaned up no matter what... But you need to keep extending the expiry while the user is still online. God forbid you create the session data before you se…
You're right that now it seems a lot of these session stores like Redis have improved. It seems they now enforce TTL and even provide sliding TTL on read. I haven't touched on this feature in a while but it used to be a major pain before.
These niceties add overhead behind the scenes but manageable... But IMO, it still falls short of the simplicity of just checking a JWT signature. In many situations, the revocation list would be relatively short compared to the number of sessions; it's a lot easier to manage... Also, critically, it's not a Single Point of Failure because the system will keep servicing users even if the revocation list is down... It just won't be able to ban users until it comes back up. This is usually a lesser concern.
Earlier quoted context omitted.
What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?
https://fly.io/blog/api-tokens-a-tedious-survey/ tl;dr: most of the time you should use opaque random strings.
Earlier quoted context omitted.
> A lot of times local storage is much less secure than using cookies. Is it? If an attacker can't do XSS then it's as strong as cookies. Supply chain attacks aren't an argument here because they can also happen with cookies. CSRF as well. The same can happen in actual executable binaries. I don't get the 20 yr age argument: - HttpOnly fights XSS which is impossible to execute with modern frontend frameworks. - SameS…
> - HttpOnly fights XSS which is impossible to execute with modern frontend frameworks. Eh. Frontend frameworks tend to make successful XSS much worse because they tend to require disabling HttpOnly for not very good reasons. HttpOnly is a nice defense in depth measure against the consequences of XSS. > - SameSite fights CSRF but the real solution is to disable loading the website in iframes (remember clickjacking?).…
First time I'm hearing that frameworks require disabling HttpOnly.
> Disabling iframes doesn't fix CSRF. You can still or tags or whatever.
Obviously. IMG tags don't work because of CORS (unless you explicitly allow this) nor script tags etc. Browsers send Origin and Sec-Fetch- headers which you can use to block POST navigation requests from other origins, like you mentioned.
But when you're using tokens in JavaScript then you don't have to worry because you already have your CSRF token, which is inaccessible to third parties and no form submit will include it. That's why local storage is more secure.
Earlier quoted context omitted.
20 years of security: sqlite3 cookies.sqlite 'SELECT name, value FROM moz_cookies WHERE isSecure AND isHttpOnly' And that's a supposedly a master password protected browser. They can't even bother encrypting cookies. Don't be ridiculous.
If the attacker can already execute code as you unrestricted, then you've kinda already lost. Local storage isn't any better in this regard
> A lot of times local storage is much less secure
Without XSS, local storage is actually more secure. You don't have worry 'did I set up this right' because there is nothing to set up and CSRF is impossible to execute.
If you're still paranoid about XSS, CSP is your friend. Also check isTrusted on events.