3 ms·

To use the most obvious examples, compare JWT to Paseto. JWT includes cryptographic agility for the client to change algorithms and and defines a “none” algori

To use the most obvious examples, compare JWT to Paseto. JWT includes cryptographic agility for the client to change algorithms and and defines a “none” algorithm that disables the cryptography altogether. The mistake is right there waiting to be made – and pretty much every single implementer made that mistake. And they keep making that mistake, over and over again [0]. Paseto doesn’t include cryptographic agility and doesn’t define a “none” algorithm. It’s quite literally impossible to make that mistake. So on the one hand, we have a protocol that we can see empirically has a design that does lead to mistakes that do lead to vulnerabilities… versus a protocol where the mistake simply can’t happen. The former “can be secure if you are careful” in this respect – which we can see very clearly means “insecure”; and the other is secure because you can’t not be careful in this respect because the protocol doesn’t allow for it. [0] https://www.howmanydayssinceajwtalgnonevuln.com https://www.howmanydayssinceajwtalgnonevuln.com

mooreds 5y ago
> JWT includes cryptographic agility for the client to change algorithms and and defines a “none” algorithm that disables the cryptography altogether. "none" is only viable in very narrow circumstances (basically where you have other ways of verifying trust, like mTLS or an isolated network AND you know that signing has a material impact on your system performance). I agree that it shouldn't be used widely. Thanks for the example. It feels a bit like the old dynamic vs static typing debate, where more flexibility can be helpful in some circumstances (monkeypatching that old ruby gem) but can come back and bit you too if you (and everyone who updates the code) are not careful. Anyway, hope Paseto (and other solutions) continue to push the ball forward. And if you are using JWTs, never accept or generate one with alg=none. :)

mooreds 5y ago

> JWT includes cryptographic agility for the client to change algorithms and and defines a “none” algorithm that disables the cryptography altogether. "none" is only viable in very narrow circumstances (basically where you have other ways of verifying trust, like mTLS or an isolated network AND you know that signing has a material impact on your system performance). I agree that it shouldn't be used widely. Thanks for the example. It feels a bit like the old dynamic vs static typing debate, where more flexibility can be helpful in some circumstances (monkeypatching that old ruby gem) but can come back and bit you too if you (and everyone who updates the code) are not careful. Anyway, hope Paseto (and other solutions) continue to push the ball forward. And if you are using JWTs, never accept or generate one with alg=none. :)