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

311–320 of 335 posts

Re: Stop Using JWTs

#311

Post by doc_ick »

tptacek wrote: post #308
doc_ick wrote: post #307

Earlier quoted context omitted.

I asked for a perfect tech in your eyes, that once created was never updated or improved upon. *edit: a recommendation for random strings in most cases isn’t perfect

In what way? Random strings are basically the gold standard. A lot of token cryptography actually destroys value already present in the random string.

You keep arguing random strings are “basically” perfect for cryptography. I’d potentially read your research paper for strings if you cited it, but my main question is what technology do you think is perfect? I don’t want to hear about misplacing pseudo-random strings until I know your basis for a perfect technology that never improves from updates.

Edit: also there have been how many attacks have there been on pseudo-random generators?

Re: Stop Using JWTs

#312

Post by tptacek »

doc_ick wrote: post #311
tptacek wrote: post #308

Earlier quoted context omitted.

In what way? Random strings are basically the gold standard. A lot of token cryptography actually destroys value already present in the random string.

You keep arguing random strings are “basically” perfect for cryptography. I’d potentially read your research paper for strings if you cited it, but my main question is what technology do you think is perfect? I don’t want to hear about misplacing pseudo-random strings until I know your basis for a perfect technology that never improves from updates. Edit: also there have been how many attacks have there been on pseud…

There have been basically no practical attacks on the LRNG or on Windows CryptGenRandom and its subsequents over the last 20+ years. People have gone of out of their way to build userspace RNGs and blown their toes off, but getrandom/urandom have been rock solid.

I think "don't use Mersenne Twister as your RNG" is a much safer bit of load-bearing advice than "use precisely these safe settings for your JWTs".

Re: Stop Using JWTs

#313

Post by jongjong »

angoragoats wrote: post #302
jongjong wrote: post #296

Earlier quoted context omitted.

My point and previous commenter's point was more about managing the session data, not the session ID itself. 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,…

> My point and previous commenter's point was more about managing the session data, not the session ID itself. Yes, I understood that clearly, and it seems that maybe you didn’t understand my post. In Rails, by default, the session data itself (not an ID) lives entirely in a cookie. No server-side session management logic of any kind is enabled or necessary. Are there situations where this isn’t the right fit? Of cou…

Haha seems you have found your arch-nemesis ;p

I wasn't familiar with the RoR implementation. We may have been talking past each other. I'm thinking about it from an access control PoV.

There are alternatives to JWT which work on the same principle but personally I haven't found any reason to move off a well established and popular format to some unknown format whose drawbacks aren't as well understood or which limits interoperability.

I checked with Claude. It seems that RoR's default is in fact its own custom implementation of a similar mechanism but with encryption instead of just signatures. This is a good approach if you want to store secret data in the session but personally I only store non-sensitive info and I prefer using JWT HS256 which is fast/cheap compared to full encryption. I try to keep my signed data light, especially if it has to be sent over the wire frequently.

I find the JWT approach more minimalist; it's only for determining account ID and privilege level, nothing else and it doesn't have to be secret. I feel like storing anything more than the bare minimum required to determine access to resources is overkill.

Re: Stop Using JWTs

#314

Post by doc_ick »

tptacek wrote: post #312
doc_ick wrote: post #311

Earlier quoted context omitted.

You keep arguing random strings are “basically” perfect for cryptography. I’d potentially read your research paper for strings if you cited it, but my main question is what technology do you think is perfect? I don’t want to hear about misplacing pseudo-random strings until I know your basis for a perfect technology that never improves from updates. Edit: also there have been how many attacks have there been on pseud…

There have been basically no practical attacks on the LRNG or on Windows CryptGenRandom and its subsequents over the last 20+ years. People have gone of out of their way to build userspace RNGs and blown their toes off, but getrandom/urandom have been rock solid. I think "don't use Mersenne Twister as your RNG" is a much safer bit of load-bearing advice than "use precisely these safe settings for your JWTs".

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

Re: Stop Using JWTs

#315

Post by angoragoats »

jongjong wrote: post #313
angoragoats wrote: post #302

Earlier quoted context omitted.

> My point and previous commenter's point was more about managing the session data, not the session ID itself. Yes, I understood that clearly, and it seems that maybe you didn’t understand my post. In Rails, by default, the session data itself (not an ID) lives entirely in a cookie. No server-side session management logic of any kind is enabled or necessary. Are there situations where this isn’t the right fit? Of cou…

Haha seems you have found your arch-nemesis ;p I wasn't familiar with the RoR implementation. We may have been talking past each other. I'm thinking about it from an access control PoV. There are alternatives to JWT which work on the same principle but personally I haven't found any reason to move off a well established and popular format to some unknown format whose drawbacks aren't as well understood or which limit…

> There are alternatives to JWT which work on the same principle

My general position is that JWTs are not well-suited or designed for web app session management, full stop. There are direct alternatives to JWTs like PASETO and Macaroons, and I don't think those are suited for session management either (though in general they are better designed from a security and simplicity perspective).

> RoR's default is in fact its own custom implementation of a similar mechanism but with encryption instead of just signatures

That's pretty much correct, with the caveat that you don't need to add a bunch of machinery with footguns galore on the frontend and backend just to be able to parse them. And as I pointed out in our last discussion, this has been the default session storage mechanism in Rails since years before JWTs existed.

> I prefer using JWT HS256 which is fast/cheap compared to full encryption

This feels like like bike-shedding for all but the largest of apps.

> I try to keep my signed data light, especially if it has to be sent over the wire frequently.

Yes, this is a recommendation for Rails' default session mechanism as well, since most browsers impose a fairly small size limit on cookies (4KiB IIRC).

> I find the JWT approach more minimalist; it's only for determining account ID and privilege level, nothing else and it doesn't have to be secret. I feel like storing anything more than the bare minimum required to determine access to resources is overkill.

There are a lot of other use cases for session data, especially if you're using a full-stack web framework vs. a SPA with a separate backend (I have strong opinions on this as well, but that's a different discussion). For example, Rails has the concept of a "flash" where you can display temporary, ephemeral messages to the user. These are stored in the session, consumed on the next request the browser makes, and then removed.

Re: Stop Using JWTs

#316

Post by tptacek »

doc_ick wrote: post #314
tptacek wrote: post #312

Earlier quoted context omitted.

There have been basically no practical attacks on the LRNG or on Windows CryptGenRandom and its subsequents over the last 20+ years. People have gone of out of their way to build userspace RNGs and blown their toes off, but getrandom/urandom have been rock solid. I think "don't use Mersenne Twister as your RNG" is a much safer bit of load-bearing advice than "use precisely these safe settings for your JWTs".

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.

Re: Stop Using JWTs

#317

Post by megous »

jkrejcha wrote: post #292
megous wrote: post #108

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

Not really. Difficulty of the attack matters. If your attack chain is silently doing an sql query over 20 year stable database format, vs something that may involve extraction of a master key from some hardened process, or tricking the user to reveal the master password to you, odds of you raising alarm in some anti-malware software raise significantly, because now you're not just reading a file, but you're using some deubgging APIs, etc., that common software does not use.

Re: Stop Using JWTs

#318

Post by jkrejcha »

szmarczak wrote: post #299
jkrejcha wrote: post #293

Earlier quoted context omitted.

> - 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?).…

> 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 Sec-Fetch-* headers) or by using SameSite on the client side (ideally both)

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

[1]: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Securit...

Re: Stop Using JWTs

#319

Post by jkrejcha »

megous wrote: post #317
jkrejcha wrote: post #292

Earlier quoted context omitted.

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

Not really. Difficulty of the attack matters. If your attack chain is silently doing an sql query over 20 year stable database format, vs something that may involve extraction of a master key from some hardened process, or tricking the user to reveal the master password to you, odds of you raising alarm in some anti-malware software raise significantly, because now you're not just reading a file, but you're using som…

The only difference between the cookie scenario and localstorage scenario here is that you're reading "storage/default//ls/data.sqlite"

It's even conveniently grouped by domain

There's no magic hardening going on with local storage (session storage is the same here), it's still SQLite

Even if so, calling ReadProcessMemory/process_vm_readv on another process really doesn't raise alarms that significantly because there are a lot of legitimate programs that do so

Re: Stop Using JWTs

#320

Post by jkrejcha »

szmarczak wrote: post #300
jkrejcha wrote: post #292

Earlier quoted context omitted.

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

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 is bad in either case (CSPs aren't usually an effective mitigation for a variety of reasons[1]) but being able to outright steal the session token is worse than being able to use it in a potentially more limited context

[1]: Primarily that they're generally just not implemented and that a lot of web frameworks require incredibly loose CSPs up to and including unsafe-eval since they often need to dynamically load JS. In addition, this doesn't protect from supply chain attacks (JS that is injected as the result of it being loaded from another domain, like from a CDN for example).

Post reply on HN