Can we finally stop conflating an encoding/signature/encryption method with a transport/storage mechanism?!
JWT is Awesome
21–30 of 170 posts
Re: JWT is Awesome
#22Earlier quoted context omitted.
Judging from the number of stars of the various git repositories for different languages, there are a few people using it but not a whole lot. The most popular implementation seems to be php based. That suggest to me it's still early days for this. E.g. the Java implementation only has 13 stars, which is not a lot. Also it has a native dependency, which is not ideal. E.g. JWT has a pure Java implementation from oauth…
Popularity != value. Get over false signals.
With lots of "security best practice" crypto constructions you can quickly find yourself needing to use unreviewed and unsupported libraries. This is a different kind of security hell.
It's worst when you're publishing an API and you need to support web clients, plus android, IOS and ideally not make things super difficult for customers using say, erlang.
As someone who used to regularly recommend things like "Use a high level / simplified library - try keyczar! Or crypto_box! etc" it has been disheartening to see how almost any even slightly niche choice will quickly devolve to developers having to pull in a bunch of dodgy looking objective-c code written say, 3 years ago by a single unknown developer.
It's usually worked out better from a whole-system perspective to stick with very widely supported standards (flawed as they are) and maintain a checklist of known footguns. It makes me sad.
Of course if your crypto is opaque to clients / not part of your integration surface then you've got a lot more wiggle room.
Perhaps what I've taken the long-winded route to getting to is, for anything where interop is important, I believe that popularity is absolutely valuable due to network effects and momentum.
Re: JWT is Awesome
#23JWTs have made client side auth integrations look better. But the problem is that common security considerations and implementation details are generally overlooked. 1. Tokens are typically stored in localStorage. (app becomes vulnerable to CSRF & XSS attacks). 2. Tokens can be stolen. Now this is generally controlled by having a very short expiration time. 3. Short expiration times mean persisting refresh tokens to…
That's a lot of work for a sessions replacement... http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
Re: JWT is Awesome
#24Was about to write a rant that it's still not better than cookies & sessions, something that has been standard waay longer than JWT. But this video says all I have to say (2018): https://www.youtube.com/watch?v=JdGOb7AxUo0 1 sec takeaway (More in the video): https://i.imgur.com/vUYTYfS.png That said, JWT's are great for stuff like 2-Factor via email link or redirecting from one domain to another. Single use, which it…
We use JWT for doing time and ip address limited cross domain redirection. We also use it for partners who want to provide sso access to our site with having to implement a full oAuth. They just provide us with their public key and use any of a number of libraries for to generate a JWT with the ip address and an short expiration and an email. Once we receive a JWT key and validate it using their public key (and other associated fields) we establish a standard cookie session.
Re: JWT is Awesome
#25Was about to write a rant that it's still not better than cookies & sessions, something that has been standard waay longer than JWT. But this video says all I have to say (2018): https://www.youtube.com/watch?v=JdGOb7AxUo0 1 sec takeaway (More in the video): https://i.imgur.com/vUYTYfS.png That said, JWT's are great for stuff like 2-Factor via email link or redirecting from one domain to another. Single use, which it…
That video is ridiculous. The whole time is spent talking about how cookies are superior to local storage which has little to do with JWT. You can use JWT and store it in a cookie. Session cookies are most certainly not automatically signed. Signing a session ID provides absolutely no value (signing claims, however, does). Revocation is exactly the same for both of them. JWT has a standard jti field for the session ID. I'm also not sure why you'd store all of a user's information in a JWT. You can just put in the minimal information to accomplish what you need.
Re: JWT is Awesome
#26Can we finally stop conflating an encoding/signature/encryption method with a transport/storage mechanism?!
Apparently not
Re: JWT is Awesome
#27I agree JWT can be very useful, but its implementations are unfortunately all over the place in terms of what algorithms they support, especially lacking in the asymmetric space. Also the docs are pretty bad—spread out over multiple documents, with no explanation of the basic concepts, and they assume a lot of pre-existing domain knowledge.
And then you still have to use JWTs correctly which is very easy to screw up. OIDC has improved this situation somewhat, at the cost of another layer of even more complexity that’s easy to screw up.
Re: JWT is Awesome
#28Everytime I see a headline with "JWT" in it, I get excited hoping that it is for "JWt" [1], the "Java Webtoolkit", which I love. It happens when I search for it as well, I look for "Jwt ..." and instead of the beloved toolkit, it comes up with all these json web tokens and HMACs. Aaah, well, I'll keep looking for that wonderful day when it really is the toolkit. I guess it goes without saying that, I recommend it highly.
Re: JWT is Awesome
#29Another Pro is that they can be read client-side, so the server and the client have an agreement on who the user is and what their attributes are (if they are defined in the JWT payload).
Re: JWT is Awesome
#30Earlier quoted context omitted.
Popularity != value. Get over false signals.
With lots of "security best practice" crypto constructions you can quickly find yourself needing to use unreviewed and unsupported libraries. This is a different kind of security hell. It's worst when you're publishing an API and you need to support web clients, plus android, IOS and ideally not make things super difficult for customers using say, erlang. As someone who used to regularly recommend things like "Use a…
That is true. The real world is dirty and messy:
- supporting public LAMP apps
- database servers that have public IP addresses that are barely filtered
- boxes not getting updates
- under-secured Linux boxes with almost every option recompiled to on
- chmod 777 developers
- substituting signatures of checksums for signatures of data
- not using HMAC and opening themselves up to length-extension and chosen plaintext attacks
- storing SSL/SSH private keys unencrypted on unencrypted laptops
- downloading HR data to a laptop and leaving it
I actually was fired once from a big name university in the SF Bay Area for refusing to haphazardly ruin the network security of a credit card processing private campus network to facilitate a new vendor remoting into terminals.
Integrity through awareness/caution, processes and standard components.
Bringing in a bunch of random dependencies, regardless of license or support status, is inviting all sorts of gaping attack surfaces.