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

Ten years of JSON Web Token and preparing for the future

self-issued.info

Post reply on HN
Print view View original

141–150 of 159 posts

Re: Ten years of JSON Web Token and preparing for the future

#141

Post by francislavoie »

cyberax wrote: post #140
francislavoie wrote: post #139

Earlier quoted context omitted.

Yes it allows Ed25519, but it doesn't disallow other curves. That's the whole point. If you allow primitives that have potential issues, it's risky to use.

There is no standard saying that implementations MUST support P-256. So you're free to just turn on Ed25519. And so far, I don't think NIST curves have been cracked? iOS secure enclave only supports them, for example.

It's not about the curves being cracked. https://auth0.com/blog/critical-vulnerability-in-json-web-en...

Re: Ten years of JSON Web Token and preparing for the future

#142

Post by bilater »

dcrazy wrote: post #137
bilater wrote: post #131

Earlier quoted context omitted.

Can you tell me of any instance where someone's auth needed to be revoked within 5 minutes and a delay was not acceptable? I think it's more of an imaginary 'five nines' engineering thing than real life.

Any time an employee is fired?

You don't tell them they are fired and then revoke access immediately. Either access is already revoked or they are given a reasonable time to close out (you have end of day before we revoke access, we will revoke access after this meeting etc). Either way a JWT expiring every second versus 5 minutes doe not change things.

I'm trying to be sensible here not dream up straw man scenarios of which there are many.

Re: Ten years of JSON Web Token and preparing for the future

#143

Post by motorest »

unscaled wrote: post #100
pwlb wrote: post #69

Earlier quoted context omitted.

You may have a look at this (still a Draft): https://datatracker.ietf.org/doc/draft-ietf-oauth-status-lis...

I don't think status lists solve the requirement for near-realtime revocations. The statuslist itself has a TTL and does not get re-loaded until that TTL expires. This is practically similar to the common practice of having a stateful refresh token and a stateless access token. The statuslist "ttl" claim is equivalent to the "exp" claim of the access token in that regard, and it comes with the same tradeoffs. You can…

> The statuslist itself has a TTL (...)

If you read the draft, the TTL is clearly specified as optional.

> (...) and does not get re-loaded until that TTL expires.

That is false. The draft clearly states that the optional TTL is intended to "specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved."

> You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses.

The concept of a TTL specifies the staleness limit, and anyone can refresh the cache at a fraction of the TTL. In fact, some cache revalidation strategies trigger refreshes at random moments well within the TTL.

There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list.

Re: Ten years of JSON Web Token and preparing for the future

#144

Post by motorest »

mattmanser wrote: post #105
the_duke wrote: post #47

Earlier quoted context omitted.

Active user logouts, deletions, permission changes are rare, so the size of revocations lists is extremely small compared to number of tokens in existence. You can keep revocations in a very fast lookup system (eg broadcasts + in-memory store), combined with reasonably short token renewals, like 5-60 minutes. Massively cuts down the number of token validity checks, and makes the system tolerant to downtimes of the au…

This makes it sound like you've only worked in an extremely narrow domain. It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration. What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else. Everyone else wants immediate revocation of rights, not w…

> What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else.

This is only conceivably true if your ability to design services only goes as far as reusing reddit-like usecases for everything and anything.

But everyone else is not incumbered by that limitation.

> Everyone else wants immediate revocation of rights, not waiting for a token to expire.

Where exactly does a JWT prevent you from rejecting revoked tokens? I mean, JWTs support short-lived tokens, jti denylists, single-user tokens with nonces, etc. Why are you blaming JWTs for problems you're creating to yourself.

Re: Ten years of JSON Web Token and preparing for the future

#145

Post by slt2021 »

unscaled wrote: post #108
methou wrote: post #15

JWTs are just too fat, and JS users often forgets encoding is not encryption. I've seen some news site trackers send JWT in url/header to some 3rd party tracker. Content is no surprise, my full name, and email address, violates its own privacy policy. Otherwise it's very open and handy, from inspecting a jwt token I can learn a lot about the architectural design of many sites.

tptacek's survey was already mentioned here, but I think it should be more famous. https://fly.io/blog/api-tokens-a-tedious-survey Unfortunately, it seems like 99% of the industry decides which token to use based on Medium articles, LLM responses or how many unmaintained packages that implement this thing they can find on NPM. JWT is mostly used as an access token, but for the vast majority of use cases it's a bad fi…

sessionID is vulnerable to stealing cookies. Some games - if you lose your session cookie, you might as well lose your account and everything you have on it.

you can of course bind sessionID to the IP address, but this is extra effort you need to put. in JWT land you can just put the IP addressed inside the payload and forward requests with non-matching IP to reauth and regenerate JWT for their new IP in case customer is roaming networks

Re: Ten years of JSON Web Token and preparing for the future

#146

Post by cyberax »

francislavoie wrote: post #138
cyberax wrote: post #134

Earlier quoted context omitted.

I am not going to watch the talk. The slides from it are unavailable either. And sorry, but the article https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... is just weak. The only real vulnerability is the key type confusion (HS256 vs. RSA256) enabled by libraries in weakly-typed languages, and easily fixed. Other: > RSA with PKCS #1v1.5 padding is vulnerable to a type of chosen-ciphertext attack, called a…

The point is that the JWT spec leaves it open to the implementer which primitives to use, which invites bad implementations to be insecure. PASETO requires a small subset of known secure primitives, preventing that problem altogether. It's not "just nonsense". Here's a list of "alg: none" JWT vulns. Every one of these would've been avoided had the standard been something like PASETO which didn't allow that. https://g…

The JWT spec can thus be fixed by changing the recommended set of primitives. No need to reinvent the wheel with custom serialization (that probably also has vulnerabilities when implemented by clueless people).

You parade the alg=none vulnerability that has been fixed long ago as the reason to reinvent the world. It's simply not.

Re: Ten years of JSON Web Token and preparing for the future

#147

Post by 5Qn8mNbc2FNCiVV »

mattmanser wrote: post #105
the_duke wrote: post #47

Earlier quoted context omitted.

Active user logouts, deletions, permission changes are rare, so the size of revocations lists is extremely small compared to number of tokens in existence. You can keep revocations in a very fast lookup system (eg broadcasts + in-memory store), combined with reasonably short token renewals, like 5-60 minutes. Massively cuts down the number of token validity checks, and makes the system tolerant to downtimes of the au…

This makes it sound like you've only worked in an extremely narrow domain. It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration. What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else. Everyone else wants immediate revocation of rights, not w…

Just press the button and get a coffee and press it again (after 5 minutes), the second time it'll be instantly revoked.

Re: Ten years of JSON Web Token and preparing for the future

#148

Post by francislavoie »

cyberax wrote: post #146
francislavoie wrote: post #138

Earlier quoted context omitted.

The point is that the JWT spec leaves it open to the implementer which primitives to use, which invites bad implementations to be insecure. PASETO requires a small subset of known secure primitives, preventing that problem altogether. It's not "just nonsense". Here's a list of "alg: none" JWT vulns. Every one of these would've been avoided had the standard been something like PASETO which didn't allow that. https://g…

The JWT spec can thus be fixed by changing the recommended set of primitives. No need to reinvent the wheel with custom serialization (that probably also has vulnerabilities when implemented by clueless people). You parade the alg=none vulnerability that has been fixed long ago as the reason to reinvent the world. It's simply not.

The spec is fundamentally flawed. The fixed spec would be a different spec, i.e. something like PASETO.

Re: Ten years of JSON Web Token and preparing for the future

#149

Post by martinald »

bilater wrote: post #131
mattmanser wrote: post #105

Earlier quoted context omitted.

This makes it sound like you've only worked in an extremely narrow domain. It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration. What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else. Everyone else wants immediate revocation of rights, not w…

Can you tell me of any instance where someone's auth needed to be revoked within 5 minutes and a delay was not acceptable? I think it's more of an imaginary 'five nines' engineering thing than real life.

Firstly I don't think most people who use JWTs use 5 min refreshes. But even assuming that - any collaboration software. Imagine you invite a user by mistake to an internal wiki, you don't really want them looking at the content for 5 minutes. Much better to be able to revoke instantly.

Then you have anything that handles financial data. If you're a bank and you get a call that you have a fraudster taking over an account; you want to be able to revoke that straight away. Waiting another 5 minutes could mean many thousands more in losses (simplified example, but you hopefully get my drift), which arguably the bank may be liable for by the regulator.

Also many other "UX" problems, you also don't want roles to be out of sync for 5 minutes. Imagine you are collaborating on a web app and you need to give a colleague write access to the system for an urgent deadline. She's sitting next to you and you have to wait 5 minutes (or do a forced login/logout) before you get access, even after refreshing the page.

Finally it's really far from ideal to be using 5 min refreshes. For idle users with a tab open you will have people constantly pinging the backend all the time to get a refresh. Imagine some sort of IOT use case where you have thousands of devices on very bandwidth limited wide area networks.

Furthermore - it's a total mess on mobile apps. Imagine you have an app (say a food delivery app) that is powered by push notifications for delivery status. If you've got a 5 min token and you push down an update via push notifications telling it to get new data from a HTTP endpoint to update a widget, your token will almost certainly be expired by the time the delivery is on the way. You then need to do a background token refresh which may or may not be possible on the OS in question.

Re: Ten years of JSON Web Token and preparing for the future

#150

Post by martinald »

bilater wrote: post #142
dcrazy wrote: post #137

Earlier quoted context omitted.

Any time an employee is fired?

You don't tell them they are fired and then revoke access immediately. Either access is already revoked or they are given a reasonable time to close out (you have end of day before we revoke access, we will revoke access after this meeting etc). Either way a JWT expiring every second versus 5 minutes doe not change things. I'm trying to be sensible here not dream up straw man scenarios of which there are many.

If you've got a rogue employee destroying stuff; you definitely do not want to wait 5 minutes.
Post reply on HN