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

301–310 of 335 posts

Re: Stop Using JWTs

#301

Post by tasuki »

tptacek wrote: post #291
tasuki wrote: post #289

Earlier quoted context omitted.

Maybe you do. Why would I have to do that?

Because it's bad to ship products where a compromised token can never be recovered from. Revocation is the essential hard problem in authentication/authorization.

I guess I just can't see the actual path here. How does a token get compromised in a way the victim finds out before the attacker makes ample use of the compromised token? From my pov, when the token gets compromised, you've lost already.

Note the auth systems I create usually do not process payment info and contain very little personal information (an email). I still think I'm fine without revocation mechanisms.

Re: Stop Using JWTs

#302

Post by angoragoats »

jongjong wrote: post #296
angoragoats wrote: post #295

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 se…

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 course. But this is one of many solutions that have been in place for decades that don’t involve using a token that is intended for short-lived and/or one-time claims.

Edit: I had a vague memory of having a very similar conversation before on HN, and it turns out it was with you. Feel free to re-read if you’d like a little more context into why I think you’re using JWTs in a way that is, at minimum, not what they were designed for:

https://news.ycombinator.com/item?id=40496378

Re: Stop Using JWTs

#303

Post by yencabulator »

andy_ppp wrote: post #143

Okay, so hack into a site that uses JWTs for login, if it’s so insecure we should be seeing loads of attacks against them right? Stolen tokens everywhere being used to impersonate people and other things. For example I believe ChatGPT is using Auth0 which uses JWTs, so you can hack this insecure token system? Should be easy right given the extremity of the warning that JWT is the big problem here.

https://cybercx.co.nz/blog/json-web-token-validation-bypass-...

Re: Stop Using JWTs

#304

Post by jcmartinezdev »

yencabulator wrote: post #303
andy_ppp wrote: post #143

Okay, so hack into a site that uses JWTs for login, if it’s so insecure we should be seeing loads of attacks against them right? Stolen tokens everywhere being used to impersonate people and other things. For example I believe ChatGPT is using Auth0 which uses JWTs, so you can hack this insecure token system? Should be easy right given the extremity of the warning that JWT is the big problem here.

https://cybercx.co.nz/blog/json-web-token-validation-bypass-...

This is really old. JWTs are very safe.

Re: Stop Using JWTs

#305

Post by yencabulator »

jcmartinezdev wrote: post #304
yencabulator wrote: post #303

Earlier quoted context omitted.

https://cybercx.co.nz/blog/json-web-token-validation-bypass-...

This is really old. JWTs are very safe.

JWT is a bad spec leading to stupid mistakes all over the ecosystem. "Just be very careful in all of the implementations forever" is a horrible security stance.

Re: Stop Using JWTs

#306

Post by owaislone »

carter2099 wrote: post #282
owaislone wrote: post #217

JWTs are awesome but they are are being overused by people. People use them in web, on mobile and everywhere in between. Places where cookie or bearer token auth has already solved the problems. JWTs strength is that it can be verified independently without real-time coordination between services. So a service can issue a JWT with auth scopes to a user. The user can take the JWT to any other service and if that servi…

> Servers must ... make DB calls to verify the user is still active I'm not being facetious, genuinely asking - is this a big deal? Should be a pretty cheap query, and with pooled connections, hardly any overhead.

Depends. If you backend is just one service, it is not a big deal but then you don't JWT at all. You just need a regular cookie/token.

If your backend is a set of 12 services where each needs to verify the authenticity of the request then it might start adding up. In that case using JWT _after_ the initial API gateway makes a lot of sense. The gateway hits the DB, authenticates the request, mints a JWT and injects it into downstream requests. Then each service on the request path just verifies the JWT.

Overall I don't think hitting the DB for auth is a big deal and that is why we don't need all the bells and whistles JWT brings. Just use bearer auth.

Re: Stop Using JWTs

#307

Post by doc_ick »

tptacek wrote: post #298
doc_ick wrote: post #297

Earlier quoted context omitted.

That’s dodging the question, and a very generic and blank recommendation.

Seems like a very specific recommendation?

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

Re: Stop Using JWTs

#308

Post by tptacek »

doc_ick wrote: post #307
tptacek wrote: post #298

Earlier quoted context omitted.

Seems like a very specific recommendation?

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.

Re: Stop Using JWTs

#309

Post by tracker1 »

tasuki wrote: post #191
tracker1 wrote: post #116

Earlier quoted context omitted.

I disagree with you and the article on this... I thought that was pretty clear. You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.

> You can use a revocation list with JWT if necessary Yes and let me just add that in many cases the use case is such that a revocation list is not even needed and then JWTs are actually stateless and it's a small win for everyone.

Exactly... especially if the expiration is a tolerance window you can handle without revocation at all. I'm a pretty big fan for using it inter-service, APIs and SPA systems.

Re: Stop Using JWTs

#310

Post by tracker1 »

unscaled wrote: post #232
beckler wrote: post #203

Earlier quoted context omitted.

The ID token is always a JWT when doing OIDC, and it makes sense in this situation. Because the ID token is not a set of credentials, but signed information you’d use to create/update a user’s profile. You can technically use JWTs as access tokens, as the spec doesn’t specify a format for access tokens, but in my experience they’re normally opaque bearer tokens.

The main reason I don't like the id token is that I've seen way too many instances of the ID token being used as a trusted identity assertion sent across multiple services or to third parties. This is very dangerous, since ID tokens tend to have longish expiry (several hours), are not revocable, and generally do not carry any concept of authorization (e.g. restricted scope). It would have been better if instead of im…

see: aud/target
Post reply on HN