3 ms·

A pretty good rule of thumb is that “…can be secure if you are careful” resolves to “insecure”. Everybody makes mistakes. Insecure protocols make it easy for m

A pretty good rule of thumb is that “…can be secure if you are careful” resolves to “insecure”. Everybody makes mistakes. Insecure protocols make it easy for mistakes to turn into vulnerabilities. Secure protocols make it difficult for mistakes to turn into vulnerabilities.

mooreds 5y ago
What's an example of a protocol that is secure even if you are sloppy/not careful? There's a spectrum of course, but 'lack of care' can cause an issue with any software system, imo.
- formerly_proven 5y ago
  You really have to try and make an insecure implementation of something like the noise protocols, for example.
- JimDabell 5y ago
  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

What's an example of a protocol that is secure even if you are sloppy/not careful? There's a spectrum of course, but 'lack of care' can cause an issue with any software system, imo.

formerly_proven 5y ago
You really have to try and make an insecure implementation of something like the noise protocols, for example.
JimDabell 5y ago
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. :)