21–30 of 115 posts
On the backend you get similar issues. Many servers default to 4kB header sizes, or 8kB, or unlimited, or anything between there. So now you get to have some fun configuring reverse proxies and node and uwsgi and tomcat and…
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
Refresh tokens are the real alternative, IMO. I kinda agree it looks like an ad for redis, since it doesn't even considers alternatives.
[0] - https://hasura.io/blog/best-practices-of-using-jwt-with-grap...
Earlier quoted context omitted.
Ya, I hate to be pedantic too, but security it almost entirely NOT binary. It should be, but it's not.
I respectfully disagree with both of you. Security should be binary, within a given set of requirements / implementation parameters and the intended threat model. Security must be binary within the space of “are you authenticated or not” (within the massive context specific web of trust and private keys) is binary and if it weren’t that would be a problem.
Holy hyperbole, Batman. This is just a straight marketing post for Redis.
I suspect the engineers that helped write this article are either very strongly for redis or cringed knowing their content would be used this way.
No system is 100% secure.
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
> 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
> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.
This article was embarrassing, and makes Redis Labs look childish and inept. Whatever process resulted in this blog post should be axed immediately, and this author should not be writing anything public facing.