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

131–140 of 159 posts

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

#131

Post by bilater »

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…

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.

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

#133

Post by kgeist »

hirsin wrote: post #115
kgeist wrote: post #55

Earlier quoted context omitted.

>We experimented once with trying to put permissions on a JWT (more complex than your popular scopes) but that makes them grow quickly. We solved it by simply using bitmasks. Say, you want to encode an access rule "allows reading from Calendar objects". The typical CRUD actions can be encoded with 4 bits. For example, all bits are zero => no access. The first bit is 1 => can create. The second bit is 1 => can read. E…

That works as long as you have no distinctions between objects of a type. _Which_ calendar can they edit? All of them? Putting all the repos you can access into a token is a request we get sometimes. It would be... Difficult.

I agree it doesn't work for all cases. In our case, some services can have complex, service-specific access control logic that's hard to express declaratively in a token, so we also have to make some checks by consulting the DB. I don't think that's usually a problem (performance-wise) because we already need to contact the DB anyway - to retrieve the entity to work with (and that has, say, an OwnerID property). The access token helps reduce DB load by skipping general checks ("can the user access calendars in principle?"), and for users who can, we then consult the DB additionally, if the service requires it ("is the user actually the owner of this calendar?" or any other additional access logic). The general case "can the user access calendars in principle?" also allows to hide menu items / return 403 in the UI immediately with zero DB or cache cost.

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

#134

Post by cyberax »

francislavoie wrote: post #33
cyberax wrote: post #31

Earlier quoted context omitted.

I fail to see how it's better, except for hand-waving about potential crypto attacks? It seems to be a NIH-ed serialization format with hard-coded ciphersuits. It doesn't seem to support use-cases like delegation and claims.

Watch the talk at the bottom of the page. JWT/JOSE are chock full of dangerous footguns that aren't just theoretical, they have repeatedly been shown to be poorly designed and too risky to implement correctly as written. Using fewer, known secure cryptographic primitives as part of the spec ensures it's impossible to get the security wrong, can't be misused.

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 padding oracle.

Not applicable.

> If you attempt to avoid invalid curve attacks by using one of the elliptic curves for security, you're no longer JWT standards-compliant.

This is just nonsense. JWT allows Ed25519: https://www.rfc-editor.org/rfc/rfc8037 Moreover, I'm not aware of real attacks against NIST curves.

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

#135

Post by afiori »

mooreds wrote: post #109
martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

> you want to be able to revoke auth straight away if an account is compromised It really depends on the system. In my experience, there are tons of apps that want to be able to revoke access but weigh that against transparent re-authentication. OIDC handles both nicely with: * short access/id token lifetimes (seconds to minutes) * regular transparent refreshes of those tokens (using a refresh token that is good for…

Imho the complexity and cost of having super short-lived access tokens is worse than eating up 1 more per-request db lookup

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

#136

Post by cyberax »

unscaled wrote: post #81
cyberax wrote: post #31

Earlier quoted context omitted.

I fail to see how it's better, except for hand-waving about potential crypto attacks? It seems to be a NIH-ed serialization format with hard-coded ciphersuits. It doesn't seem to support use-cases like delegation and claims.

these "potential crypto attacks" resulted in multiple CVEs and several real life attacks. I think even the Storm-0558[1] could be traced to how hard it is verify a valid JWT, due to some of the over-engineering mistakes that have been involved in the standard's design. I don't know if PASETO would have solved that particular attacks, but the PASETO standard solves some of the most common CVEs we see with JWT librarie…

It looks like in the case of MS they simply trusted an incorrect key in the validation path? I fail to see how PASETO would have solved that. There were no token format shenanigans.

`alg=none` and `hsa=rsa` were really the only ones that are JWT-specific. Invalid curves are algorithm-specific, and JWT allows the Ed25519 signatures.

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

#137

Post by dcrazy »

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.

Any time an employee is fired?

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

#138

Post by francislavoie »

cyberax wrote: post #134
francislavoie wrote: post #33

Earlier quoted context omitted.

Watch the talk at the bottom of the page. JWT/JOSE are chock full of dangerous footguns that aren't just theoretical, they have repeatedly been shown to be poorly designed and too risky to implement correctly as written. Using fewer, known secure cryptographic primitives as part of the spec ensures it's impossible to get the security wrong, can't be misused.

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://github.com/zofrex/howmanydayssinceajwtalgnonevuln/bl...

You say "I am not going to watch the talk" and then you continue to argue in bad faith. Please walk away if you're not going to engage honestly.

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

#139

Post by francislavoie »

cyberax wrote: post #136
unscaled wrote: post #81

Earlier quoted context omitted.

these "potential crypto attacks" resulted in multiple CVEs and several real life attacks. I think even the Storm-0558[1] could be traced to how hard it is verify a valid JWT, due to some of the over-engineering mistakes that have been involved in the standard's design. I don't know if PASETO would have solved that particular attacks, but the PASETO standard solves some of the most common CVEs we see with JWT librarie…

It looks like in the case of MS they simply trusted an incorrect key in the validation path? I fail to see how PASETO would have solved that. There were no token format shenanigans. `alg=none` and `hsa=rsa` were really the only ones that are JWT-specific. Invalid curves are algorithm-specific, and JWT allows the Ed25519 signatures.

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.

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

#140

Post by cyberax »

francislavoie wrote: post #139
cyberax wrote: post #136

Earlier quoted context omitted.

It looks like in the case of MS they simply trusted an incorrect key in the validation path? I fail to see how PASETO would have solved that. There were no token format shenanigans. `alg=none` and `hsa=rsa` were really the only ones that are JWT-specific. Invalid curves are algorithm-specific, and JWT allows the Ed25519 signatures.

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.

Post reply on HN