5 ms·

Paseto is better https://paseto.io/ https://paseto.io/, but unfortunately OAuth forces the usage of JWT.

cyberax 1y ago
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.
- francislavoie 1y ago
  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.
  - cyberax 1y ago
    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-bad-standard-that-everyone-should-avoid 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 https://www.rfc-editor.org/rfc/rfc8037 Moreover, I'm not aware of real attacks against NIST curves.
    - francislavoie 1y ago
      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/blob/deploy/data/vulns.yml 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.
      - cyberax 1y ago
        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.
        francislavoie 1y ago
        The spec is fundamentally flawed. The fixed spec would be a different spec, i.e. something like PASETO.
        cyberax 1y ago
        You keep repeating that. What is "fundamentally flawed"? PASETO has exactly the same vulnerabilities. You can specify a different version, and a buggy implementation can misinterpret it. With PASETO, the algorithm selection is fully under the control of the attacker.
- unscaled 1y ago
  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 libraries: alg=none, Algorithm Confusion attacks and invalid curves. [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/ https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
  - cyberax 1y ago
    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.
    - francislavoie 1y ago
      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.
      - cyberax 1y ago
        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.
        francislavoie 1y ago
        It's not about the curves being cracked. https://auth0.com/blog/critical-vulnerability-in-json-web-encryption/ https://auth0.com/blog/critical-vulnerability-in-json-web-en...
JimDabell 1y ago
I believe OAuth doesn’t require JWT (just an opaque token, which in practice is often JWT), but OpenID Connect – which is based on OAuth – does require JWT.
- khana 1y ago
  [dead]
- unscaled 1y ago
  Some optional OAuth extension RFCs do depend on JWT, e.g. Profile for OAuth 2.0 Access Tokens (RFC 9068) OAuth 2.0 Demonstrating Proof of Possession (DPoP) (RFC 9449, JWT-Secured Authorization Request (JAR) (RFC 9101). Core OAuth 2.0 does not enforce supporting JWT anywhere, but due to the influence of OpenID Connect there are more and more OAuth use cases that require JWT if you want to follow standards beyond the core OAuth RFCs (6749 and 6750). The closest OAuth gets to mandating JWT is with client authentication and proof-of-possession. The OAuth Best Current Practices RFC (9700) recommends using asymmetric JWT for client authentication in case you cannot use Mutual TLS (which is usually the case). This recommendation will probably be rolled into the new OAuth 2.1 standard (it is included in the draft). OAuth 2.1 also mentions the JWT-based DPoP as one of the two recommended methods for implementing sender-constrained access tokens (the other one is Mutual TLS again).
deleted 1y ago
[deleted]
Zamicol 1y ago
{ "pay": { "msg": "There are also other options.", "alg": "ES256", "iat": 1748248973, "tmb": "9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk", "typ": "cyphr.me/msg/create" }, "sig": "sHyMrykhsta5etjqH1e5oho0EpEs2FrblQ0DFHQo0aMgKd2V__SQ2Fl2EOSKt8wl65iLmKgIaMVEgCmhtvbUcg" } Verify: https://cozejson.com https://cozejson.com Spec: https://github.com/Cyphrme/Coze https://github.com/Cyphrme/Coze
- hirsin 1y ago
  Hm, I wonder how the double sig problem that SAML would run into will work here. What happens if someone adds an extra sig object there?
- francislavoie 1y ago
  I don't like it much, using JSON as the transport has some problems if encoded in a URL as required by many auth flows. Paseto encodes the whole version+payload+signature to make it easier to transport. Of course you could just base64 encode the whole Coze JSON, but that isn't part of the spec, which means the spec is weak.
mooreds 1y ago
> OAuth forces the usage of JWT. OAuth doesn't, OIDC does for the ID token[0]. OAuth, at least the inital RFCs, were released 3 years before JWT was defined. But many extensions of OAuth do require or support JWTs. Either way, I'm just not sure the demand is there. My employer has had an open issue for Pasteo[1] for years but hasn't seen much community support. Some other interesting comments here[2]. Looks like most of the implementations[3] are libraries rather than standalone auth servers. 0: https://openid.net/specs/openid-connect-core-1_0.html#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke... 1: https://github.com/fusionAuth/fusionauth-issues/issues/773 https://github.com/fusionAuth/fusionauth-issues/issues/773 2: https://www.reddit.com/r/KeyCloak/comments/1e2h5w7/is_paseto_really_better_than_jwt/ https://www.reddit.com/r/KeyCloak/comments/1e2h5w7/is_paseto... 3: https://paseto.io/ https://paseto.io/
- francislavoie 1y ago
  As others have said, JWT, in practice, is effectively forced by the extensions/OIDC, I was just being short. It shouldn't be about demand. It's about solving the danger of these poorly designed APIs to improve overall web security.

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.

francislavoie 1y ago
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.
- cyberax 1y ago
  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-bad-standard-that-everyone-should-avoid 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 https://www.rfc-editor.org/rfc/rfc8037 Moreover, I'm not aware of real attacks against NIST curves.
  - francislavoie 1y ago
    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/blob/deploy/data/vulns.yml 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.
    - cyberax 1y ago
      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.
      - francislavoie 1y ago
        The spec is fundamentally flawed. The fixed spec would be a different spec, i.e. something like PASETO.
        cyberax 1y ago
        You keep repeating that. What is "fundamentally flawed"? PASETO has exactly the same vulnerabilities. You can specify a different version, and a buggy implementation can misinterpret it. With PASETO, the algorithm selection is fully under the control of the attacker.
unscaled 1y ago
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 libraries: alg=none, Algorithm Confusion attacks and invalid curves. [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/ https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
- cyberax 1y ago
  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.
  - francislavoie 1y ago
    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.
    - cyberax 1y ago
      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.
      - francislavoie 1y ago
        It's not about the curves being cracked. https://auth0.com/blog/critical-vulnerability-in-json-web-encryption/ https://auth0.com/blog/critical-vulnerability-in-json-web-en...

JimDabell 1y ago

I believe OAuth doesn’t require JWT (just an opaque token, which in practice is often JWT), but OpenID Connect – which is based on OAuth – does require JWT.

khana 1y ago
[dead]
unscaled 1y ago
Some optional OAuth extension RFCs do depend on JWT, e.g. Profile for OAuth 2.0 Access Tokens (RFC 9068) OAuth 2.0 Demonstrating Proof of Possession (DPoP) (RFC 9449, JWT-Secured Authorization Request (JAR) (RFC 9101). Core OAuth 2.0 does not enforce supporting JWT anywhere, but due to the influence of OpenID Connect there are more and more OAuth use cases that require JWT if you want to follow standards beyond the core OAuth RFCs (6749 and 6750). The closest OAuth gets to mandating JWT is with client authentication and proof-of-possession. The OAuth Best Current Practices RFC (9700) recommends using asymmetric JWT for client authentication in case you cannot use Mutual TLS (which is usually the case). This recommendation will probably be rolled into the new OAuth 2.1 standard (it is included in the draft). OAuth 2.1 also mentions the JWT-based DPoP as one of the two recommended methods for implementing sender-constrained access tokens (the other one is Mutual TLS again).

deleted 1y ago

[deleted]

Zamicol 1y ago

{ "pay": { "msg": "There are also other options.", "alg": "ES256", "iat": 1748248973, "tmb": "9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk", "typ": "cyphr.me/msg/create" }, "sig": "sHyMrykhsta5etjqH1e5oho0EpEs2FrblQ0DFHQo0aMgKd2V__SQ2Fl2EOSKt8wl65iLmKgIaMVEgCmhtvbUcg" } Verify: https://cozejson.com https://cozejson.com Spec: https://github.com/Cyphrme/Coze https://github.com/Cyphrme/Coze

hirsin 1y ago
Hm, I wonder how the double sig problem that SAML would run into will work here. What happens if someone adds an extra sig object there?
francislavoie 1y ago
I don't like it much, using JSON as the transport has some problems if encoded in a URL as required by many auth flows. Paseto encodes the whole version+payload+signature to make it easier to transport. Of course you could just base64 encode the whole Coze JSON, but that isn't part of the spec, which means the spec is weak.

mooreds 1y ago

> OAuth forces the usage of JWT. OAuth doesn't, OIDC does for the ID token[0]. OAuth, at least the inital RFCs, were released 3 years before JWT was defined. But many extensions of OAuth do require or support JWTs. Either way, I'm just not sure the demand is there. My employer has had an open issue for Pasteo[1] for years but hasn't seen much community support. Some other interesting comments here[2]. Looks like most of the implementations[3] are libraries rather than standalone auth servers. 0: https://openid.net/specs/openid-connect-core-1_0.html#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke... 1: https://github.com/fusionAuth/fusionauth-issues/issues/773 https://github.com/fusionAuth/fusionauth-issues/issues/773 2: https://www.reddit.com/r/KeyCloak/comments/1e2h5w7/is_paseto_really_better_than_jwt/ https://www.reddit.com/r/KeyCloak/comments/1e2h5w7/is_paseto... 3: https://paseto.io/ https://paseto.io/

francislavoie 1y ago
As others have said, JWT, in practice, is effectively forced by the extensions/OIDC, I was just being short. It shouldn't be about demand. It's about solving the danger of these poorly designed APIs to improve overall web security.