(First of all, I want to make it clear that I have no idea whether he's right or wrong. That is precisely the reason I am posting this).Randall Degges is an experienced security expert and he did this talk, which is actually pretty entertaining to watch and very well presented, which nice slides and stuff:https://www.youtube.com/watch?v=pYeekwv3vC4I got back to the web dev industry not along ago, so all of this is new to me. That's why I am now extremely confused. Basically, he says that Session Cookies beat JWT in pretty much every department when it comes to login systems.Since most people probably won't watch a one hour video, he also posted this on Github (and got most upvotes for it):"This is a really interesting topic. The talk linked to above is my talk which I'm always happy to discuss. It's quite hard to sum it all up into a short Github comment though.The gist of it is this:JWTs are larger than randomly generated API tokens because with JWTs you store data in them for stateless benefits which increases their size. Bigger size means more latency from the user to your API which means slower connections. And... If you aren't storing data in the JWT and are using it purely as a random string then you're negating any benefit they might have at all. Now they're just oversized string IDs.JWTs, by design, are meant to be used to store cached data. That's their only use case in the entire world. And that is exactly what you don't want to do if you're building a secure web service: a website, API, IoT device, or anything in between. From the moment you decide to start caching authentication and authorization data in a client-side token you've opened yourself up to security issues because you're trusting that the data you receive is correct and valid. And... If you don't trust that data (or want to revoke tokens when needed) then you need to build some sort of centralized revocation list which again: negates any benefit you might have gotten from a JWT in the first place. This goes back to the original security vs. speed argument: it is truly impossible to have a secure anything if you're using cached data to validate your user.Setting a short-lived JWT TTL is basically a shitty way of saying that "I want security and speed" but really accomplishes none of either: if you have a short-lived TTL you're still vulnerable to using invalid cached data and you most certainly won't be able to revoke tokens when needed (and if you can... then you are using centralization again and negating all JWT benefits).Finally: if you realize JWTs are basically security anti-patterns but still want to use them you might think "OK: I'll just use a JWT but I'll only use it once and never rely on cached data." But if you do this then it goes back to argument 1 -- JWTs are simply less efficient API keys (or session IDs). They're accomplishing the same thing except with extra complexity/size over the wire which serves nobody any good and only complicates something simple.In pretty much every single situation imaginable JWTs are worse than just using a randomly generated API key of some sort (or session ID if we're talking about web apps). There is no benefit to using them, only downsides.Instead of using JWTs my recommendation is to keep it extremely simple:If you're building a web app of some sort use server side sessions and store a cryptographically signed (and optionally encrypted) session ID as a randomly generated string on the client. Cache session data with invalidation in the backend if you want speed.If you're building an API service of some sort generate random string API Key IDs and Secrets as key pairs for your users. Follow the same rules above: cache things server side if you want with invalidation for speed.If security is a major concern: store API key secrets hashed using a fast algorithm (intended to allow for many concurrent lookups without hammering CPU/memory/cores with "good" algorithms like argon2, scrypt, and bcrypt). This way key secrets are unrecoverable (like what AWS does) and you can trust them slightly more."Both the video and the post got me really confused, since there are a bunch of tutorials out there encouraging you to use JWT's for login systems.Some people say he made this video because he works for a company that offers a paid login service, but that is not really a valid/strong argument against his statements.That is why I would like to know what you think about all these claims.
Submitted May 29, 2020 at 08:02AM by Paullang18
No comments:
Post a Comment