[nathanmills]

Geez, I need to re-sign in every time my mobile data switches IP?? IPs are NOT static. Mobile networks change IPs CONSTANTLY. What if I use a VPN (I do) and my IP changes constantly? What if an IOT device on your network is serving as a public residential proxy that anyone can use (more common than you may think), or hell, you have CGNAT and your neighbor does? What if an entire country only goes through one IP[1]? Have you done this in practice?

[1] https://en.wikipedia.org/wiki/User:82.148.97.69

[amarant]

The IP field in particular: no. It was a top of my head solution to a situation that's pretty much fucked. The scenario where an attacker gets control of a client machine is very hard to defend against, regardless of Auth scheme.

But hey, since jwt is so insecure, why don't you go ahead and hack my Minecraft account? I implemented the JWT -based Auth they use, and my username is iworkatmojang.

Get back to me when you've changed my password

[CodeLieutenant]

I've never said JWT is insecure. It's just hard to do it right, even with libraries. Most libraries just give you HERE IS THE SIGNED TOKEN, but everything else is on you. I've implemented JWT many, many times, and I'm really tired of implementing the same thing over and over again. Most of the things you do is boilerplate, but If you never thought about this boilerplate you're vulnerable.

It can be done right, but it's harder than doing something else. Take it like this: IF YOU KNOW WHAT YOU ARE DOING, OK, FINE, GOOD LUCK IF YOU DONT, STICK TO SOMETHING SIMPLER.

Simple solutions are better solutions, and developer time is important. Do you want to maintain simple authentication layer or you want this complex machinery, upgrade library, check for CVE, validate the library implementation, read the RFC. At that point I would be like... NO, I wanna go and do other things I'm interested in.

[nathanmills]

No, I will not send you malware. This scenario is about post-hacked where the malware is removed, but the attacker still has the cookies they collected. There should be a way to invalidate those cookies, just like how you can change your password if they got your password.

If you want, however, we can simulate the scenario. Find your JWT token, change your password (commonly invalidates tokens aswell), and then post it here post-invalidation. If it works still, then thats the issue. Though, changing your password commonly requires your current password and not just a cookie, so I wouldn't be able to do that. But I could probably change your username as proof. If it doesn't work, then it was checked against some revocation database that the article talks about, where at that point, where you have you check a database anyway, you might as well just store the session on the server, since the JWT is no longer stateless and provides no advantage over typical sessions.