Node-jsonwebtoken: What should I (non-cryptographer) have in mind when using this package?
What should I (non-cryptographer) have in mind when using this package in the light of this article;
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid ?
walleboom
>All comments
I'm a Security Engineer at Auth0.
Most (but not all) of the concerns raised in that article we consider legitimate. However, we disagree that those concerns justify the conclusion the article makes (in its title, no less). The JWT spec has - like many cryptographic specifications intended for industry use - issues around (a) promoting reasonable choices and sensible defaults for use vs. maintaining widespread applicability and cryptographic agility, and (b) balancing the formalism required by the mathematical arguments that underpin security and the practical demands of implementation. What this ultimately means is that the specification cannot, unfortunately, be respected in general for it's recommendations nor taken as a source of truth - the ECDH-ES vulnerability, as mentioned in the article and original publicized in a blog post published on our own site (https://auth0.com/blog/critical-vulnerability-in-json-web-encryption/) is an example of where the specification failed to provide a satisfactory level of correctness.
With that said, these concerns are not universal to the specification - the JWT, JOSE, JWA, JWS, and JWE specs are ultimately nomenclature and encoding schemes - and those algorithms which have been widely analyzed by cryptographers and which are simply and commonly implemented we maintain confidence in. The algorithms supported by this library - RSASSA, ECDSA, and the standardized HMAC from RFC 2104 all used with SHA2 - are just such constructions. As such, we are confident in the integrity and message authentication guarantees this library purports to provide. As the blog post notes, using JWTs for session management is not always the right choice. But when it is, we believe this library provides for their secure and effective use.
sjudson
on 15 Mar 2017
Related issues
usamamashkoor
路
4Comments
rockchalkwushock
路
4Comments
itamarwe
路
3Comments
Teebo
路
4Comments
samholmes
路
5Comments
Most helpful comment
I'm a Security Engineer at Auth0.
Most (but not all) of the concerns raised in that article we consider legitimate. However, we disagree that those concerns justify the conclusion the article makes (in its title, no less). The JWT spec has - like many cryptographic specifications intended for industry use - issues around (a) promoting reasonable choices and sensible defaults for use vs. maintaining widespread applicability and cryptographic agility, and (b) balancing the formalism required by the mathematical arguments that underpin security and the practical demands of implementation. What this ultimately means is that the specification cannot, unfortunately, be respected in general for it's recommendations nor taken as a source of truth - the ECDH-ES vulnerability, as mentioned in the article and original publicized in a blog post published on our own site (https://auth0.com/blog/critical-vulnerability-in-json-web-encryption/) is an example of where the specification failed to provide a satisfactory level of correctness.
With that said, these concerns are not universal to the specification - the JWT, JOSE, JWA, JWS, and JWE specs are ultimately nomenclature and encoding schemes - and those algorithms which have been widely analyzed by cryptographers and which are simply and commonly implemented we maintain confidence in. The algorithms supported by this library - RSASSA, ECDSA, and the standardized HMAC from RFC 2104 all used with SHA2 - are just such constructions. As such, we are confident in the integrity and message authentication guarantees this library purports to provide. As the blog post notes, using JWTs for session management is not always the right choice. But when it is, we believe this library provides for their secure and effective use.