Holy hyperbole, Batman. This is just a straight marketing post for Redis.
The irony is: redis and memcached are not great for storing sessions either.
Why not? Every large system I’ve ever seen used one of these for sessions.
JWT Tokens are NOT safe
71–80 of 115 posts
Re: JWT Tokens are NOT safe
#72Earlier quoted context omitted.
You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. They could be refreshed or if using OAuth, simply redirect an unauthenticated user and they’ll be reissued based on the cookies stored by the OAuth provider… assuming the redirect doesn’t break your app of course. Alternatives? First, you could live with the possibility that tokens are valid for some period of tim…
> You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. The author argues that you can't revoke a JWT - suggesting that 30min is the usual default. To their point, if 30min is too long, then 10min is probably still too long. However, implying that 30min is too long for a token to remain stale suggests that you aren't really working at the scale that JWT was destined…
Could you expand on why 30min session validity after explicit logout is okay? I don’t mean to sound accusatory; I would like to understand your reasoning.
Re: JWT Tokens are NOT safe
#73Question: do these arguments not apply to any certificate authority system? Token (cert private key) lifetime, revocation lists, stale data?
Re: JWT Tokens are NOT safe
#74It's an ad for Redis. If you're spending too much time looking up the credentials associated with a session cookie, you're doing something wrong. Maybe you need a cache. Sure, sometimes it won't be in cache, but it probably will be.
The cache can be redis.
Re: JWT Tokens are NOT safe
#75Earlier quoted context omitted.
You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. They could be refreshed or if using OAuth, simply redirect an unauthenticated user and they’ll be reissued based on the cookies stored by the OAuth provider… assuming the redirect doesn’t break your app of course. Alternatives? First, you could live with the possibility that tokens are valid for some period of tim…
I do want to follow up - there are two parts of JWT issuing that are problems and why I prefer using JWTs only issued by OAuth providers (third-parties that know what they’re doing) - 1. JWT tokens you issue yourself might not have expiry dates in them - I am assuming that your JWT tokens are valid for a reasonable duration such as 2 hours or less, otherwise you should probably use a different technology - and 2. Lik…
Don’t be so sure about the third-party auth providers. Even Auth0 accidentally allowed token validation bypass by specifying a weird capitalization of “none” for the algorithm. https://insomniasec.com/blog/auth0-jwt-validation-bypass
Re: JWT Tokens are NOT safe
#76OK, 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.
Simple session tokens are fine, always have been.
Re: JWT Tokens are NOT safe
#77I don't think these arguments hold up:
> 1. If someone gets access to your token [after you're logged out] they can continue to access it until it expires.
The author goes on to say that "security is binary — either it’s secure or it’s not". So... Is the token secure, or is it not?
If we can't assume that we have the capability to transmit and securely clear a string from the client, the whole discussion becomes somewhat pointless because both methods of authentication are borked.
> 2. Blocking users doesn’t immediately block them.
If you want to block a user, why would you block the JWT? Block the userId, or some other identifier that isn't coupled to a transient authentication mechanism.
> 3. Could have stale data. Imagine the user is an admin and got demoted to a regular user with fewer permissions. . .
This example demonstrates that this would not be good information to store in a JWT and blindly trust. Store a user identifier (or another immutable and unique identifier) and look up their permissions with that.
> 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.
Encrypting the token doesn't make it harder or easier to sniff a token or to re-use it. Assuming the author isn't suggesting that people are transmitting literal account credentials unencrypted, this is the same point as #1 above because encryption and signing are meant to prevent against other attacks.
Re: JWT Tokens are NOT safe
#78Earlier quoted context omitted.
You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. They could be refreshed or if using OAuth, simply redirect an unauthenticated user and they’ll be reissued based on the cookies stored by the OAuth provider… assuming the redirect doesn’t break your app of course. Alternatives? First, you could live with the possibility that tokens are valid for some period of tim…
> You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. The author argues that you can't revoke a JWT - suggesting that 30min is the usual default. To their point, if 30min is too long, then 10min is probably still too long. However, implying that 30min is too long for a token to remain stale suggests that you aren't really working at the scale that JWT was destined…
I absolutely agree. That’s why I said:
> you could live with the possibility that tokens are valid for some period of time after logout because it usually doesn’t matter - generally you delete the cookie and the user is logged out, even if technically they could restore the cookie later. They won’t, unless you’re under attack.
Re: JWT Tokens are NOT safe
#79I flagged this post for the following reason:
Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.
The user's submission history is almost completely RedisLabs content.
Re: JWT Tokens are NOT safe
#80> 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.
Nothing is "secure or not" - technologies/mitigations are secure against particular attacks. HTTPS is generally secure against passive network eavesdropping, but does nothing to stop local file inclusion in a web app. Just because there are attacks or ways around a particular defense doesn't mean it's worthless, that's why we have defense in depth.
This. That's why they call them 'attack vectors'.
I disagree with the main thesis for why JWT is a problem. JWT isn't necessarily encouraging you not to hit the DB for user lookup. This is the claim the article makes as a problem with revocation.
It reads like a really long thoughtful article based entirely on false assumptions for how to best use it.
It's ok to carry around some encrypted state in your tokens for some uses cases.