3 ms·
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 verif
by 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 agoIt 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 agoYes 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 agoThere 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 agoIt'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...