7 ms·

Tired: {"alg":"none"} Wired: {"alg":"nonE"} The JOSE standards (including JWT) are a gift that keeps on giving to attackers. I designed an alternative format

Tired: {"alg":"none"} Wired: {"alg":"nonE"} The JOSE standards (including JWT) are a gift that keeps on giving to attackers. I designed an alternative format in 2018 called PASETO, which doesn't contain the JOSE foot-guns. (I'm pushing for an IETF RFC this year.) https://paseto.io https://paseto.io EDIT: Also, this affected their Authentication API rather than their JWT library. If you use their JWT library, well, it certainly allows this kind of horrendous misuse... but it is not, per se, vulnerable.

bflesch 6y ago
Paseto is a great project, thank you very much for your contribution!
ucarion 6y ago
What IETF WG are you working through?
- CiPHPerCoder 6y ago
  CFRG
  - ucarion 6y ago
    Good luck! Seems like previous discussions with the mailing list could have gone better, but PASETO seems like promising work!
  - tptacek 6y ago
    Are there links to more recent discussions on CFRG? Did you take any of the critiques from CFRG to heart? I think the v1/v2 local/public points were well-taken.
    - CiPHPerCoder 6y ago
      Nothing from 2020 yet. XChaCha has to be prioritized first.
kyrra 6y ago
(googler, opinions are my own) For server-to-server, I continue to prefer PGP to provide my encryption. While Google Payments[0] supports PGP and JWE for encrypting payloads, PGP is well tested and most of the bugs have been worked out. JWS/JWE continues to have implementation bugs (likely due to being too flexible). [0] https://developers.google.com/standard-payments/reference/best-practices https://developers.google.com/standard-payments/reference/be...
- CiPHPerCoder 6y ago
  PGP isn't great either: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html Better options for PGP use cases: - AWS Encryption SDK: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html https://docs.aws.amazon.com/encryption-sdk/latest/developer-... - age https://age-encryption.org https://age-encryption.org - Magic Wormhole https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole - NaCl/libsodium (and/or usability wrappers) https://libsodium.gitbook.io/doc/ https://libsodium.gitbook.io/doc/ Better options for JWE use cases: - PASETO: https://paseto.io https://paseto.io - Branca: https://branca.io https://branca.io
  - kyrra 6y ago
    PGP definitely has it's issues. It is a good tool for dealing with files, but yeah, it has it's problems. It looks like Google's security team prefers the use of Tink[0] when having to encrypt things. [0] https://github.com/google/tink https://github.com/google/tink
    - CiPHPerCoder 6y ago
      Yes, Tink is acceptable too. :)
    - cordite 6y ago
      Tink is great! I wish there were more supported languages. AEAD and AWS KMS to decrypt the key set is perfect for our needs.
grinich 6y ago
I think we're going to use PASETO for some stuff at WorkOS. Thanks for building it. :)
OatMilkLatte 6y ago
I'm going to use PASETO for a personal project I'm working on. If the COVID lockdown ever ends and I have time to work on it. Thanks for building it!
different_sort 6y ago
Why a new standard than to push for reform to the current standard? Are they just closely protected by greybeards who won't listen to reason? Question comes from a true place of ignorance/curiosity, I definitely understand the need to have unambiguous, easy to implement security tokens without the foot-guns.
- CiPHPerCoder 6y ago
  Simple answer: Because secure cryptography is backwards-incompatible with insecure cryptography, and the JOSE standards have a lot of legacy cruft that will be hard to jettison. If you're going to put in the work (which I am), you might as well start with a clean slate rather than trying to piecemeal security improvements into their design-by-committee spec.
  - different_sort 6y ago
    Thank you for your reply!
- pillfill 6y ago
  > Why a new standard than to push for reform to the current standard? Or even just an opinionated library with some basic guardrails to prevent bad configurations.
  - kelnos 6y ago
    That's tempting, but as long as a standard has design flaws, there will be libraries out there that don't prevent bad configurations, and people (through innocent ignorance) will use them and end up in a bad place.
  - blattimwind 6y ago
    The whole point of modern cryptography is to take all the oodles of rope to hang yourself with and hand it over to the cryptographers, to leave just the absolute minimum amount of rope with the application developers. JWT is the opposite of that. It's essentially a reenactment of the bad parts of 90s crypto, including RSA and NONE ciphers.
Nursie 6y ago
We use it, but restrict the sig alg to a couple of known-good values, so am hoping this particular vulnerability is not present in our system. We had an infosec guy excitedly tell us that PASETO was the future, and we need to change to it right now. It looked good, and a way to avoid some of the possible JiWY issues in the same way having a TLS implementation that only allowed strong ciphers might. But we have to integrate with so many third party pieces that require JWT it wasn't an option.
speedgoose 6y ago
Before starting a new project some time ago, I read about the critics to JOSE (JWE) and the alternative PASETO. I decided to use JOSE carefully instead of PASETO because it had an IETF RFC. I think it will be great for PASETO to get a RFC as well. The second point that made me chose JOSE was that PASETO was a bit too mean towards JOSE, and I didn't want drama in my technology choices. But good work! With a RFC PASETO will be my choice for my next projects.
dwaite 6y ago
> I'm pushing for an IETF RFC this year. Are you planning an informational document, or going through the IETF standardization process? Also, the last published draft is two years old this week. Have there been changes since then to the spec? Are implementations generally interoperable?
- CiPHPerCoder 6y ago
  I'll be sending an email to CFRG, probably next week, with any spec changes. But before I resuscitate PASETO, XChaCha20 needs an RFC. It's pending IRTF kick-off. https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03 https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03

bflesch 6y ago

Paseto is a great project, thank you very much for your contribution!

ucarion 6y ago

What IETF WG are you working through?

CiPHPerCoder 6y ago
CFRG
- ucarion 6y ago
  Good luck! Seems like previous discussions with the mailing list could have gone better, but PASETO seems like promising work!
- tptacek 6y ago
  Are there links to more recent discussions on CFRG? Did you take any of the critiques from CFRG to heart? I think the v1/v2 local/public points were well-taken.
  - CiPHPerCoder 6y ago
    Nothing from 2020 yet. XChaCha has to be prioritized first.

kyrra 6y ago

(googler, opinions are my own) For server-to-server, I continue to prefer PGP to provide my encryption. While Google Payments[0] supports PGP and JWE for encrypting payloads, PGP is well tested and most of the bugs have been worked out. JWS/JWE continues to have implementation bugs (likely due to being too flexible). [0] https://developers.google.com/standard-payments/reference/best-practices https://developers.google.com/standard-payments/reference/be...

CiPHPerCoder 6y ago
PGP isn't great either: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html Better options for PGP use cases: - AWS Encryption SDK: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html https://docs.aws.amazon.com/encryption-sdk/latest/developer-... - age https://age-encryption.org https://age-encryption.org - Magic Wormhole https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole - NaCl/libsodium (and/or usability wrappers) https://libsodium.gitbook.io/doc/ https://libsodium.gitbook.io/doc/ Better options for JWE use cases: - PASETO: https://paseto.io https://paseto.io - Branca: https://branca.io https://branca.io
- kyrra 6y ago
  PGP definitely has it's issues. It is a good tool for dealing with files, but yeah, it has it's problems. It looks like Google's security team prefers the use of Tink[0] when having to encrypt things. [0] https://github.com/google/tink https://github.com/google/tink
  - CiPHPerCoder 6y ago
    Yes, Tink is acceptable too. :)
  - cordite 6y ago
    Tink is great! I wish there were more supported languages. AEAD and AWS KMS to decrypt the key set is perfect for our needs.

grinich 6y ago

I think we're going to use PASETO for some stuff at WorkOS. Thanks for building it. :)

OatMilkLatte 6y ago

I'm going to use PASETO for a personal project I'm working on. If the COVID lockdown ever ends and I have time to work on it. Thanks for building it!

different_sort 6y ago

Why a new standard than to push for reform to the current standard? Are they just closely protected by greybeards who won't listen to reason? Question comes from a true place of ignorance/curiosity, I definitely understand the need to have unambiguous, easy to implement security tokens without the foot-guns.

CiPHPerCoder 6y ago
Simple answer: Because secure cryptography is backwards-incompatible with insecure cryptography, and the JOSE standards have a lot of legacy cruft that will be hard to jettison. If you're going to put in the work (which I am), you might as well start with a clean slate rather than trying to piecemeal security improvements into their design-by-committee spec.
- different_sort 6y ago
  Thank you for your reply!
pillfill 6y ago
> Why a new standard than to push for reform to the current standard? Or even just an opinionated library with some basic guardrails to prevent bad configurations.
- kelnos 6y ago
  That's tempting, but as long as a standard has design flaws, there will be libraries out there that don't prevent bad configurations, and people (through innocent ignorance) will use them and end up in a bad place.
- blattimwind 6y ago
  The whole point of modern cryptography is to take all the oodles of rope to hang yourself with and hand it over to the cryptographers, to leave just the absolute minimum amount of rope with the application developers. JWT is the opposite of that. It's essentially a reenactment of the bad parts of 90s crypto, including RSA and NONE ciphers.

Nursie 6y ago

We use it, but restrict the sig alg to a couple of known-good values, so am hoping this particular vulnerability is not present in our system. We had an infosec guy excitedly tell us that PASETO was the future, and we need to change to it right now. It looked good, and a way to avoid some of the possible JiWY issues in the same way having a TLS implementation that only allowed strong ciphers might. But we have to integrate with so many third party pieces that require JWT it wasn't an option.

speedgoose 6y ago

Before starting a new project some time ago, I read about the critics to JOSE (JWE) and the alternative PASETO. I decided to use JOSE carefully instead of PASETO because it had an IETF RFC. I think it will be great for PASETO to get a RFC as well. The second point that made me chose JOSE was that PASETO was a bit too mean towards JOSE, and I didn't want drama in my technology choices. But good work! With a RFC PASETO will be my choice for my next projects.

dwaite 6y ago

> I'm pushing for an IETF RFC this year. Are you planning an informational document, or going through the IETF standardization process? Also, the last published draft is two years old this week. Have there been changes since then to the spec? Are implementations generally interoperable?

CiPHPerCoder 6y ago
I'll be sending an email to CFRG, probably next week, with any spec changes. But before I resuscitate PASETO, XChaCha20 needs an RFC. It's pending IRTF kick-off. https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03 https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03