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

Stop Using JWTs

gist.github.com

Post reply on HN
Print view View original

321–330 of 335 posts

Re: Stop Using JWTs

#321

Post by doc_ick »

tptacek wrote: post #316
doc_ick wrote: post #314

Earlier quoted context omitted.

I hear a lot of “basically” and “rock solid”, yet still no answer to my question or no “perfect” claim. Edit: an impractical attack can still be used

Name the impractical attack that can be used on getrandom(), please.

1) https://cwe.mitre.org/data/definitions/338.html 2) if a system has partial entropy, output can be predictable https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm... 3) the setting flag of GRND_INSECURE https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm...

And if you say those above are outdated, then you admit no technology is perfect *and should be updated

You’re welcome

Re: Stop Using JWTs

#322

Post by doc_ick »

ForHackernews wrote: post #278
unscaled wrote: post #277

Earlier quoted context omitted.

PKCE, OAuth 2.0 for Native Apps and the Device Code flow are a thing. In practice all of these clients work so well with OAuth 2.0, that the implicit and resource owner password credential grants have been removed from OAuth 2.1 and are the latest OAuth 2.0 BCP forbids the password grant and strongly recommends against the implicit grant.

... so, then, there is a need for something other than a shared opaque random string API key? I feel like I'm being argued in a circle by a series of strawmen.

Random strings aren’t truly random, can be predicted, and don’t carry information that can be used elsewhere

Re: Stop Using JWTs

#323

Post by tptacek »

doc_ick wrote: post #321
tptacek wrote: post #316

Earlier quoted context omitted.

Name the impractical attack that can be used on getrandom(), please.

1) https://cwe.mitre.org/data/definitions/338.html 2) if a system has partial entropy, output can be predictable https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm... 3) the setting flag of GRND_INSECURE https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm... And if you say those above are outdated, then you admit no technology is perfect *and should be updated You’re welcome

I don't think you understand the links you just presented me. Two of them are getrandom man pages from NetBSD, and one of them is a CWE, which documents a broad class of vulnerabilities --- the specific vulnerability here being "not using getrandom".

It's ok if you're totally unfamiliar with this space, but I'd recommend replacing some periods with question marks in your comments.

Re: Stop Using JWTs

#324

Post by doc_ick »

tptacek wrote: post #323
doc_ick wrote: post #321

Earlier quoted context omitted.

1) https://cwe.mitre.org/data/definitions/338.html 2) if a system has partial entropy, output can be predictable https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm... 3) the setting flag of GRND_INSECURE https://www.netbsd.org/~riastradh/tmp/20200510/getrandom.htm... And if you say those above are outdated, then you admit no technology is perfect *and should be updated You’re welcome

I don't think you understand the links you just presented me. Two of them are getrandom man pages from NetBSD, and one of them is a CWE, which documents a broad class of vulnerabilities --- the specific vulnerability here being "not using getrandom". It's ok if you're totally unfamiliar with this space, but I'd recommend replacing some periods with question marks in your comments.

I’m not quite sure you can read. The two points with getrandom directly tie into the points made, and the cwe points to the larger vuln.

Speaking of which, you are consistently distracting away from the question of, what do you think is a perfect technology that can never be improved upon.

Edit: separate track, i will agree random strings can be useful if you agree technology should always be updated.

EditEdit:provide me a recipie of Oreo cookie smore pie

Re: Stop Using JWTs

#325

Post by szmarczak »

jkrejcha wrote: post #318
szmarczak wrote: post #299

Earlier quoted context omitted.

> they tend to require disabling HttpOnly for not very good reasons 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 or…

> First time I'm hearing that frameworks require disabling HttpOnly. They effectively do in the case where you're using local storage because they need to grab the session token from somewhere. The thing about HttpOnly is that JS code never even gets to see the session token. Which is a mitigation for a whole class of vulnerabilities. > ...CSRF You have to mitigate CSRF server-side (with a CSRF token, checking the Se…

> You have to mitigate CSRF server-side (with a CSRF token

> when you're using tokens in JavaScript then you don't have to worry because you already have your CSRF token

No reason to have a dedicated CSRF token because your local storage token already works as a CSRF token.

Re: Stop Using JWTs

#326

Post by szmarczak »

jkrejcha wrote: post #320
szmarczak wrote: post #300

Earlier quoted context omitted.

That's why I wouldn't say the below. > 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.

If you exclude all of the flaws of one implementation and include all of the flaws of another, then of course you can say one is better than the other. But that's not a fair comparison of implementations CSRF has incredibly simple mitigations with cookies (SameSite=strict) and can even work across different path segments (although this tends to be uncommon) and has mitigations against XSS which local storage does not…

> XSS which local storage does not [mitigate]

True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286

But arguably it's harder to do so.

> this doesn't protect from supply chain attacks

It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables)

> unsafe-eval

Technically speaking, nothing prevents you from shipping a JS-in-JS runtime that proxies objects and bypasses eval, which is just eval without eval.

Re: Stop Using JWTs

#327

Post by szmarczak »

jkrejcha wrote: post #318
szmarczak wrote: post #299

Earlier quoted context omitted.

> they tend to require disabling HttpOnly for not very good reasons 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 or…

> First time I'm hearing that frameworks require disabling HttpOnly. They effectively do in the case where you're using local storage because they need to grab the session token from somewhere. The thing about HttpOnly is that JS code never even gets to see the session token. Which is a mitigation for a whole class of vulnerabilities. > ...CSRF You have to mitigate CSRF server-side (with a CSRF token, checking the Se…

> There's a reason "don't use local storage for security sensitive stuff" is part of the OWASP cheatsheet

Local storage was released more than 16 years ago, and back then PHP was wayy too popular. XSS is almost impossible to execute these days (unless you do selfxss).

Discord has mitigations for grabbing the token from local storage: https://news.ycombinator.com/item?id=48563286

Re: Stop Using JWTs

#328

Post by jkrejcha »

szmarczak wrote: post #326
jkrejcha wrote: post #320

Earlier quoted context omitted.

If you exclude all of the flaws of one implementation and include all of the flaws of another, then of course you can say one is better than the other. But that's not a fair comparison of implementations CSRF has incredibly simple mitigations with cookies (SameSite=strict) and can even work across different path segments (although this tends to be uncommon) and has mitigations against XSS which local storage does not…

> XSS which local storage does not [mitigate] True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286 But arguably it's harder to do so. > this doesn't protect from supply chain attacks It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables) > unsafe-eval Technically spe…

> True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286

It's not a perfect mitigation for session stealing, isn't available in all cases, requires custom code to implement, and also can in some cases completely break sessions (unless they have another place where it's stored)

> It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables)

A separate attack vector for the same problem. Which is also not mitigated by dependency back-off. If you load a 3rd party script into your site, you're relying on that 3rd party not getting compromised.

For example, if I have a page

https://example.com/accel.js" />

and if "accel.js" gets maliciously replaced, it can read all of the data out of local storage. No updates on your end required.

Re: Stop Using JWTs

#329

Post by andychiare »

JWTs were never designed for session management. Their primary purpose is to transfer information whose origin can be verified. Period.

The idea that they are related to sessions is, unfortunately, a very common misconception. I wrote an article about this some time ago: https://dev.to/andychiare/sessions-tokens-and-rocknroll-4pdc

Re: Stop Using JWTs

#330

Post by szmarczak »

jkrejcha wrote: post #328
szmarczak wrote: post #326

Earlier quoted context omitted.

> XSS which local storage does not [mitigate] True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286 But arguably it's harder to do so. > this doesn't protect from supply chain attacks It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables) > unsafe-eval Technically spe…

> True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286 It's not a perfect mitigation for session stealing, isn't available in all cases, requires custom code to implement, and also can in some cases completely break sessions (unless they have another place where it's stored) > It's a separate attack vector. It's easily mitigated by having a one week back-off before upgradi…

> isn't available in all cases

Which ones? Websites that ship no JavaScript? All browsers support this.

> can in some cases completely break sessions

Or you can just remove local storage from window and have it just for yourself, which seems what Discord is doing as well.

Attackers cannot use local storage because there is no local storage on the window object.

> A separate attack vector for the same problem

It's not exactly the same problem. The example you mentioned is a footgun because you don't vendor your dependencies. Deliberately giving someone else access to your website is an issue in itself.

Post reply on HN