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

121–130 of 335 posts

Re: Stop Using JWTs

#121

Post by adithyassekhar »

szmarczak wrote: post #10

No need to stop. The XSS argument also applies when using cookies. JWTs are just tokens like session data but in JSON format. What format you choose to go with doesn't matter. You can keep storing JWTs in local storage and still be secure. Discord removes it on page load and restores it when the tab is closed. Also if your website is susceptible to XSS, skill issue, exactly like in the case of SQL injections. That wo…

> Discord removes it on page load and restores it when the tab is closed.

How does this work? You have no real control over what the browser does when it closes a tab.

Re: Stop Using JWTs

#122

Post by miiiiiike »

zdragnar wrote: post #73
miiiiiike wrote: post #33

Security doesn't start or end with JWTs. A user wants to access a read-only resource with an invalid JWT? Envoy bounces it without passing the request through to the backend. Valid JWT? Let the request through without having to look up any session information. No DB, no cache, no session server hit. Fast. A user wants to change a password, email address, or add an authenticator? First, require a password, second, req…

> look for the JWT access token in a revocation list that is only accessed during sensitive, infrequent, requests I've clearly spent too much time working with data covered by HIPAA because this sentence gave me a brief bit of panic. The vagueness and extent of what it technically covers means it's far safer to just assume literally everything about your users needs maximum security.

This is the eternal conversation around auth. “The thing you do doesn’t work for the thing I do.” OK. Use something else.

Re: Stop Using JWTs

#123

Post by 10000truths »

littlecranky67 wrote: post #53
jpalomaki wrote: post #45

Earlier quoted context omitted.

Session data lookup is one select to database that gives 0..1 rows and uses index. In most cases this is not something you need to worry about.

I agree. The storage space, however, is a different story. Your session DB can grow huge, depending on your session lifetime and your users logout behaviour. Plus, it is a concern in a distributed system (i.e. a token can be validated on every node, vs. a session lookup must be globally in sync)

1. For the vast majority of CRUD apps, active sessions will be a very small fraction of the actual storage requirements. A SaaS with 100K MAU may have only 100 or so active users at any given time.

2. Sessions by definition are ephemeral. A database should not be necessary at all, an in-memory cache should suffice.

3. If you really need to distribute session data across multiple nodes, just propagate them asynchronously. Authentication and authorization are semantically idempotent operations. Having to possibly re-auth when making a cross-region request within milliseconds of logging in might be mildly annoying for the user, but consistency isn't a deal breaker here.

Re: Stop Using JWTs

#124

Post by littlecranky67 »

10000truths wrote: post #123
littlecranky67 wrote: post #53

Earlier quoted context omitted.

I agree. The storage space, however, is a different story. Your session DB can grow huge, depending on your session lifetime and your users logout behaviour. Plus, it is a concern in a distributed system (i.e. a token can be validated on every node, vs. a session lookup must be globally in sync)

1. For the vast majority of CRUD apps, active sessions will be a very small fraction of the actual storage requirements. A SaaS with 100K MAU may have only 100 or so active users at any given time. 2. Sessions by definition are ephemeral. A database should not be necessary at all, an in-memory cache should suffice. 3. If you really need to distribute session data across multiple nodes, just propagate them asynchronou…

> 3. If you really need to distribute session data across multiple nodes

What you mean, "if" - you will need that once you are international. You can't afford to verify every http request against a centralized session store when you have users in Australia, US, Europe, Japan etc. You can't beat the speed of light. My point is, replicating revocation lists that are append-only, only a small megabytes, and can be publicly known, is always easier than syncing session databases for a complexity standpoint.

Re: Stop Using JWTs

#125

Post by 0x696C6961 »

RagingCactus wrote: post #16
solatic wrote: post #3

Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication. edit: I read some of the linked stuff, e.g. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Please, if JWTs are such a horrifically insecure standard, go ahead and publish your means for hacking AWS STS's AssumeRoleWithWebIdentity , or don't publish and just exploit it by launchin…

> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…

The design I've landed over the years is to use both. The cookie is a session token and that's where you handle refresh tokens. Then there's an endpoint where you can mint a short-lived tenant-sepecific JWT. This holds the scopes & tenant id. The session token only lets you access the web assets & mint JWT tokens.

Re: Stop Using JWTs

#126

Post by jiveturkey »

saganus wrote: post #112
nine_k wrote: post #19

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…

I am still waiting for Macaroons to be used widely. I think they are a fantastic invention. It seems they were not of very much use in the past, but with the agentic-everything now, I see this as a great way of delegating permissions to subagents, third-party agents, etc. Working on something along these lines but unfortunately I cannot dedicate as much time as I'd like. Still, if anyone is reading, give Macaroons a…

JWTs can do that (delegate) and such capability is already well defined.

Re: Stop Using JWTs

#127

Post by tptacek »

ForHackernews wrote: post #119
tptacek wrote: post #115

Earlier quoted context omitted.

You've completely missed my point. I don't even accept the premise of the JWT standard. But the eventual migration to safer default settings, in a format that continues to expend implementation effort to support settings nobody should use, is in fact a practical engineering problem with the standard.

And they've published updates[0] and libraries have hardened their defaults and removed support for insecure values (e.g. alg='none'). I'm not sure what more you want? I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system sy…

I don't recommend PASETO either.

Re: Stop Using JWTs

#128

Post by y2244 »

agwa wrote: post #65
robertlagrant wrote: post #61

Earlier quoted context omitted.

> While common JWT libraries have now mostly got their stuff together, this has not always been the case. There were plenty of libraries accepting the "none" algorithm [1] or allowing attackers to forge tokens by using a public key as a shared secret [2]. This is the direct result of the complexity criticized in the linked blog post. I'm a bit surprised at this. These are extremely simple to solve - the first time I…

You would think so, but even an authentication company screwed it up: https://cybercx.co.nz/blog/json-web-token-validation-bypass-...

Wow lol

Re: Stop Using JWTs

#130

Post by figassis »

RagingCactus wrote: post #117
figassis wrote: post #101

Earlier quoted context omitted.

Stateless JWT revocation: https://blog.nellcorp.com/new-aproach-to-jwt-revocation/

> First, we need to add a token_secret column to our users table: > ALTER TABLE users ADD COLUMN token_secret; So it's "stateless" but we have to query the users database on every request? How is that more stateless than SELECT * FROM session WHERE id = cookie? Ignoring that and taking the mechanism as given: Why the obsession with cryptography, in this case HMAC? I don't see any reason why another signature is neede…

You don't actually have to do a db trip to get a user secret and revoke a token. A token comes in, and you can store the secret in the same place you store your application secret. Because you do need to store it, cache it, whatever. The point here is you no longer need to keep a revocation database of every token you issued that is still unexpired. Just rotate the signing secret and every token issued until then will be revoked. Goes from maintaining millions of tokens to maintaining a smaller cache of user secrets that are probably rarely updated.

Why not an epoch? because this gives control to the user. They can now logout regardless of token ttl. The point is not obsessing over crypto, JWTs are a cryptographic solution, it's what makes them stateless and I have nothing agains cookies or any other session token. I use them interchangeably.

My pain point was that whenever I needed to use a JWT or whenever I worked a company that used JWTs, their main frustration was "oh but then we can't revoke them easily without maintaining a revocation list". Well now they don't have to.

Telling them just migrate to "this or that technology" is not how this works.

Post reply on HN