11–20 of 304 posts
This post says "it's insecure if you do it wrong". Well.....
> JSON Web Signatures Makes Forgery Trivial
> 1. Send a header that specifies the "none" algorithm be used
Most JWT libraries require you to explicitly allow the none algorithm. I had to set a very explicit system property to even get the library I am using to accept none! Even so, anyone implementing JWT should make sure that only the algorithms actually used are accepted.
> 2. Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key.
Being able to use the public RSA key used to sign an RS256 JWT as the key for a (forged) HS256 token requires the server to accept both RS256 and HS256, and (critically) to be able to use a key configured for RSA assymetric signing to validate HMAC SHA256 signatures. I have not been able to reproduce this latter bug with the library I am using, but even if it did, I still check the algorithm field beforehand: if a token claims it is HS256 signed, I use the (private) key configured for that (if HMAC SHA256 signing is allowed in my application); if it is RS256 signed, I use the (public) key configured for that. The library I use doesn't even get a choice in this; it either receives a JWT that claims to be RS256 together with a RSA 2048 public key, or it gets a JWT that claims to be HS256 together with a private signing key exlcusively used for HS256.
The code preforming those checks between the REST-call receiving the JWT and the JWT library is trivial.
This is all assuming that you would place a service configured to accept both HS256 and RS256 tokens at the same time in production.
As with any security standard: don't use crap libraries; do your research; test your service for common vulnarabilities; follow recommendations made by experts; and don't deploy techniques you don't quite grasp in production software.
> JSON Web Encryption is a Foot-Gun
So is TLS, or hashing passwords. Security is hard and requires a lot of reading and grokking (but it is not too hard for any moderately experienced software engineer).
> TL;DR
Really? 'Too long; didn't read' for a handful of paragraphs? I'll grant the author this much; anyone who can't muster the attention span to read that much text without groping around for a single sentence summary shouldn't be implementing (any!) security standards.
JSON Web Token is a well-documented accessible security standard with a lot of comprehensive information available. As with any technique, there are caveats, but these caveats do not discredit the technique as a whole.
This is based on what? Sounds like he just made it up. His other claims does not look sound to much more either. I would like to see a more in-depth analysis on the subject, this all looks very hand-wavy to me.
"Send a header that specifies the "none" algorithm be used" Why would an issuer ever let a client decide what algo to use? "Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key." Again, under what circumstances would a header be used by the client to ask for a specific implementation? What about encrypted client side cookies - would you let the client…
If these things are suggested in the standard and promptly followed by major implementations, then the standard isn't very good.
The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header ( https://github.com/auth0/node-jsonwebtoken/blob/master/verif... ) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your a…
It would really help encourage the uptake of better alternatives like libsodium if it were standardized. Just referencing some random library can scare decision makers; whereas referencing an IETF official document or ISO standard makes them just take it as given. The same problem exists with serialization formats - you have XML and JSON, both of which are standardized and have an "official face", although JSON was n…
The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header ( https://github.com/auth0/node-jsonwebtoken/blob/master/verif... ) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your a…
Because JSON Web Tokens are short-lived, the blacklist need only contain tokens valid for validity period plus a few seconds and remains very small (often empty).
If you use JWT to allow authorization on several server, then you do need to distribute this blacklist, so it is not a completely trivial solution. In the simplest scenario you might suffice with only maintaining a blacklist on the server that can refresh tokens (this means that when the token expires, a new one cannot be automatically acquired).
"Send a header that specifies the "none" algorithm be used" Why would an issuer ever let a client decide what algo to use? "Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key." Again, under what circumstances would a header be used by the client to ask for a specific implementation? What about encrypted client side cookies - would you let the client…
> The only problems you highlighted are serious input validation issues and a naive, broken trust model. If these things are suggested in the standard and promptly followed by major implementations, then the standard isn't very good.
JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.
I've been using headerless JWTs for stateless API authentication and authorization (JWT without the first segment), but the work is preliminary and I wonder if I'm doing it wrong.