[catamphetamine]

https://redislabs.com/blog/json-web-tokens-jwt-are-dangerous...

> 1. Logout doesn’t really log you out!

That is true, but if someone intercepts a token then they can already see all the data (or perform all the actions), even before the user logs out, so this doesn't count as a flaw.

> 2. Blocking users doesn’t immediately block them.

Lame. A simple blacklist would suffice. The blacklist entries would expire after the lifetime of a generic token. Since the blacklist is small, it could fit in server's RAM and be fast. Or it could be stored somewhere in Redis.

> 3. Could have stale data. > Imagine the user is an admin and got demoted to a regular user with fewer permissions.

Lame. Just block the old token on any privilige changes. All roles are stored in a token anyway, so if a user's priviliges change, then all the user's tokens should be included in the blacklist.

> 4. JWT’s are often not encrypted so anyone able to perform a man-in-the-middle attack and sniff the JWT now has your authentication credentials.

Not even true. There're no credentials in the token. There's just a user ID and that's it.

> It’s been found that many libraries that implement JWT have had many security issues over the years.

And Linux kernel has had many bugs. So what now? Not use Linux?

> In many complex real-world apps, you may need to store a ton of different information.

And storing it in the JWT tokens could exceed the allowed URL length or cookie lengths causing problems. Lame. No one uses cookies or URL for that. No one stores enormous amounts of data in a JWT.

> In many real-world apps, servers have to maintain the user’s IP and track APIs for rate-limiting and IP-whitelisting.

Not a valid argument. Those apps aren't even many, they're a very small portion. Very small, almost zero.

> One popular solution is to store a list of “revoked tokens” in a database and check it for every call. And if the token is part of that revoked list, then block the user from taking the next action. But then now you are making that extra call to the DB to check if the token is revoked and so deceives the purpose of JWT altogether.

They aren't very smart, are they? Because they don't even see a difference between a short in-memory list and a database full of users records.

> Bottom line

Bottom their ass

[echelon]

None of your security postures will fly at any organization with an infosec team.

AuthN/AuthZ is one of the most important areas to lock down.

[catamphetamine]

So you don't have to say anything on point. Just abstract imaginary accusations. Move along.

[echelon]

I worked for two years on a session system for an institution that cared deeply about security.

We had to trace, kill, kill all for single or multiple sessions, users, or organizations. Do this for entire IP ranges, client versions, or client ids. Rate limit all "session-mutating" (unidirectional state machine) actions, time out, model session confidence, restrict session scopes (subset authz), associate with any entity written or touched, monitor lists of compromised emails and passwords, require 2fa...

Your opinions might work where money and privacy aren't involved. But I wouldn't trust your posture with my bank info, emails, or personal messages.

What happens if your signing key leaks? Or you accidentally log session JWTs? Or someone's device goes missing, or someone steals a password, or an account manager has their info posted openly?

We're not worried about just our entire database. We're worried about any ATO, undesired action, or data leak, however small. Even one impacted person is too many.

Security really fucking matters. Take it seriously or don't touch it.

[cphoover]

I don't get why you couldn't have a panic bit set the same way you maintain an in memory revocation leak... Also I don't get how this is any different than "what if a DB password" leaks?

What if someone steals a device and copies the httpOnly cookies from the network developer inspector tab then forges the requests using Curl?

I don't see how these problems are unique to JWTs and how they exist unmitigated with the use of in-memory revocation list.