[grassfedgeek]

JWT can be short-lived, for example 1 hour. Then on each request if the token is nearing expiration you decide whether to extend it or not, and if so return a replacement JWT with extended expiration. With a short-lived JWT you don't need to invalidate the JWT.

> just put the JWT in an httpOnly cookie

You can have two cookies, one that is signed and httpOnly, and another that is unsigned and readable by JavaScript. Both contain the same information. So JavaScript can read the information in the second cookie, but since it is unsigned, exfiltrating the cookie doesn't compromise security.

[CodeLieutenant]

Still the same problem, if your account is compromised, you cannot invalidate the session, same for web, same for native app. You need to store it so that it can be blacklisted.

[nathanmills]

Let's say a friend sends you an exe file, a game they made. You run it, and immediately realize it wasn't actually your friend. The attacker has stolen your JWT session cookie. The attacker hasn't done anything yet - they are configuring their browser cookies to match yours. You go to invalidate your session / change your password, but it doesn't help. The attacker has a full hour to do whatever they want on your account. They use it to send the same malicious exe from your account. If you would've been able to invalidate the session, you could've stopped it.

[grassfedgeek]

> and immediately realize

That's a narrow scenario isn't it, if you have to "immediately" realize?

[jeroenhd]

The pattern described is a common Discord account theft method and it has proven very effective at locking people out of their accounts.

[grassfedgeek]

The example requires immediate action. If the hacker beats you he can lock you out by taking over the account, it doesn't matter if it is JWT or some other tech.

[nathanmills]

Why would it require immediate action? Most chat services have a rate limit, stopping them at ANY point prevents it from spreading further. The messages don't get all sent at once, they will use the full access period to send as much as they can. Accounts can't typically be taken over with just a cookie, changing passwords normally requires you to confirm your current one. I hope you haven't designed any services where a cookie is enough to lock people out.

[nathanmills]

No, it's called an example. I refuse to provide an example for every possible scenario, as that would not fit in the Hacker News comment limit.

[znpy]

> Let's say a friend sends you an exe file, a game they made.

1995 called, they want their lame hacking tecniques back

[amarant]

Add a client IP field to the JWT. Token is only valid if the request comes from the associated IP. Done.

[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.