3 ms·
IMHO the proposed API fix is also risky. I can see someone trying to be clever and simply extracting "alg" from the header themselves, feeding it to verify(), a
by nly 11y ago
IMHO the proposed API fix is also risky. I can see someone trying to be clever and simply extracting "alg" from the header themselves, feeding it to verify(), and then thinking "Jeez, why isn't this library smart enough to do this for me?". Someone copying and pasting the snippet to Stack Overflow to do just that would be inevitable. A better fix might be to make like /etc/shadow and stick the algorithm type on to the front of the encoded secret key.
[Rant] Optionally use a statically typed language that supports overloading of the original, nice simple, function instead of doing crypto on malleable data formats in dynamically typed languages and expecting good results... if you go to the JWT homepage[0] you'll see all the statically-typed languages are unaffected by this vulnerability. Coincidence?
[0] http://jwt.io/ http://jwt.io/
- tracker1 11y agothat's only half the suggested fix, the other half is to remove alg from the header altogether... In practice, I've always ignored the alg header, and just used the expected alg for my implementations.