4 ms·

> the author gives no real alternatives to JOSE. He does that right below the title: "Update (March 2018): Paseto is a Secure Alternative to the JOSE Standards

> the author gives no real alternatives to JOSE. He does that right below the title: "Update (March 2018): Paseto is a Secure Alternative to the JOSE Standards (JWT, etc.)"

thefounder 7y ago
I can't find the specification/rfc of Paseto. It looks more of a php lib. To me it seems the author is not familiar with JWT[0] and tries to solve the wrong problems(e.g assumes the idp or library being used are compromised.) [0] >> This decodes to: Version: v2 Purpose: local (shared-key authenticated encryption) Payload (hex-encoded): JWT has an 'aud' param that serves the same purpose as "Purpose" here and more. Versioning makes it even worse and doesn't solve any security issue. If v1 is compromised the client should not be allowed to use it.
- fraktl 7y ago
  From your two comments, it's clear you skimmed the text you're trying to discuss here. How can your opinion be regarded as relevant in any way? You highlight that author is not familiar with something (he is, he's actually well respected expert who explains everything in fine detail), yet you've shown you don't read carefully at all. I found PASETO's website, rfc and github within.. 3 seconds of using my PC. I'm 100% sure you're capable of doing the same. Your comment looks like unnecessary criticism because you feel provoked since someone criticized a piece of technology you use.
  - thefounder 7y ago
    Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE (i.e only secure alg; no "none" option etc) and at the same time develop a secure by default JOSE library rather than to invent a new protocol, with a new format and new libraries? I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP.
    - lvh 7y ago
      PASETO is designed to be resilient against insecure implementation, just as its primitives were. You can do things to make stuff like Ed25519 unsafe (see, for example, a myriad of double-spend attacks), but they involve off-label use, which PASETO precludes. By contrast, JWT was clearly not designed to be resilient against insecure implementation. A cryptographic engineer reading the spec would already have snorted milk through their nose at the sight of the "alg" header, the primitives included PKCSv15 RSA as a default _years_ after we knew it was unsafe, et cetera. A strict JOSE might help, but I think it'll be ineffectual. There's little incentive to move ("we already audited this") and there's lots of incentive to stay because compatibility concerns reach further than security ("Cognito does this weird thing with base64 codas that is different from everyone else and we have to support Cognito"). Consider flipping it around as a thought experiment: if you were willing to give up compatibility, and you were going to integrate a new library anyway, why not go whole hog and do a protocol that was always safe?
    - fraktl 7y ago
      > Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE It would, I agree 100%. Less options and less standards we have - the better. I support your notion here.
    - CiPHPerCoder 7y ago
      > I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP. The specification is here: https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs If you can write an insecure implementation without violating the specification, please file an issue on Github.
      - skrebbel 7y ago
        Here's another thing I like about PASETO: because it's versioned, communicating about insecurities found further down the line is much easier. With JWT you have to say stuff like "ensure that alg can't be 'none' and that your JWT library doesn't accept arbitrary alg fields". This is messy. With PASETO you can just say "be sure to use v3 or later" (assuming someone finds a flaw in v2, files that issue, and that is then addressed in a v3 of the spec). Similarly, implementations can just write "supports versions 1 through 3" on their README.
- CiPHPerCoder 7y ago
  > I can't find the specification/rfc of Paseto. https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs https://paseto.io/rfc/ https://paseto.io/rfc/ > It looks more of a php lib. https://paseto.io/ https://paseto.io/ -- Several languages implement PASETO. > To me it seems the author is not familiar with JWT[0] How does one demonstrate familiarity with JWT beyond analyzing/critiquing the RFCs for JWT and correlating the specific language of the standard with real-world vulnerabilities of JWT implementations? > and tries to solve the wrong problems(e.g assumes the idp or library being used are compromised.) Assuming something that has happened several times already isn't a "wrong problem". https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
lifeisstillgood 7y ago
I would be interested in seeing where that lies in the occassional "Cryptographic right answers" threads

> the author gives no real alternatives to JOSE. He does that right below the title: "Update (March 2018): Paseto is a Secure Alternative to the JOSE Standards (JWT, etc.)"

thefounder 7y ago

I can't find the specification/rfc of Paseto. It looks more of a php lib. To me it seems the author is not familiar with JWT[0] and tries to solve the wrong problems(e.g assumes the idp or library being used are compromised.) [0] >> This decodes to: Version: v2 Purpose: local (shared-key authenticated encryption) Payload (hex-encoded): JWT has an 'aud' param that serves the same purpose as "Purpose" here and more. Versioning makes it even worse and doesn't solve any security issue. If v1 is compromised the client should not be allowed to use it.

fraktl 7y ago
From your two comments, it's clear you skimmed the text you're trying to discuss here. How can your opinion be regarded as relevant in any way? You highlight that author is not familiar with something (he is, he's actually well respected expert who explains everything in fine detail), yet you've shown you don't read carefully at all. I found PASETO's website, rfc and github within.. 3 seconds of using my PC. I'm 100% sure you're capable of doing the same. Your comment looks like unnecessary criticism because you feel provoked since someone criticized a piece of technology you use.
- thefounder 7y ago
  Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE (i.e only secure alg; no "none" option etc) and at the same time develop a secure by default JOSE library rather than to invent a new protocol, with a new format and new libraries? I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP.
  - lvh 7y ago
    PASETO is designed to be resilient against insecure implementation, just as its primitives were. You can do things to make stuff like Ed25519 unsafe (see, for example, a myriad of double-spend attacks), but they involve off-label use, which PASETO precludes. By contrast, JWT was clearly not designed to be resilient against insecure implementation. A cryptographic engineer reading the spec would already have snorted milk through their nose at the sight of the "alg" header, the primitives included PKCSv15 RSA as a default _years_ after we knew it was unsafe, et cetera. A strict JOSE might help, but I think it'll be ineffectual. There's little incentive to move ("we already audited this") and there's lots of incentive to stay because compatibility concerns reach further than security ("Cognito does this weird thing with base64 codas that is different from everyone else and we have to support Cognito"). Consider flipping it around as a thought experiment: if you were willing to give up compatibility, and you were going to integrate a new library anyway, why not go whole hog and do a protocol that was always safe?
  - fraktl 7y ago
    > Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE It would, I agree 100%. Less options and less standards we have - the better. I support your notion here.
  - CiPHPerCoder 7y ago
    > I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP. The specification is here: https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs If you can write an insecure implementation without violating the specification, please file an issue on Github.
    - skrebbel 7y ago
      Here's another thing I like about PASETO: because it's versioned, communicating about insecurities found further down the line is much easier. With JWT you have to say stuff like "ensure that alg can't be 'none' and that your JWT library doesn't accept arbitrary alg fields". This is messy. With PASETO you can just say "be sure to use v3 or later" (assuming someone finds a flaw in v2, files that issue, and that is then addressed in a v3 of the spec). Similarly, implementations can just write "supports versions 1 through 3" on their README.
CiPHPerCoder 7y ago
> I can't find the specification/rfc of Paseto. https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs https://paseto.io/rfc/ https://paseto.io/rfc/ > It looks more of a php lib. https://paseto.io/ https://paseto.io/ -- Several languages implement PASETO. > To me it seems the author is not familiar with JWT[0] How does one demonstrate familiarity with JWT beyond analyzing/critiquing the RFCs for JWT and correlating the specific language of the standard with real-world vulnerabilities of JWT implementations? > and tries to solve the wrong problems(e.g assumes the idp or library being used are compromised.) Assuming something that has happened several times already isn't a "wrong problem". https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-...

lifeisstillgood 7y ago

I would be interested in seeing where that lies in the occassional "Cryptographic right answers" threads