Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JWT Tokens are NOT safe

redislabs.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: JWT Tokens are NOT safe

#51

Post by hamburglar »

colesantiago wrote: post #3

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.

There’s no reason to put all the user info in redis and this article makes no valid argument for it. Give the token a unique ID and store that ID in redis (or some other fast store). Validate the token by checking its sig and verifying that its ID is in redis. Store all the signed metadata you want on the client, revoke it by removing its ID from redis. Addresses all cases where the token is stale. So basically redis becomes your token whitelist, not your store of user metadata. Problem solved.

Signed blobs of data such as certificates and web tokens are a very powerful massively distributed cache where the entity that benefits from the data being cached is also the entity responsible for persisting it. This is a wonderful optimization whose sole drawback is that you need an external way to decide when that entry is invalid. Solve that problem, don’t abandon the entire concept of the distributed cache.

Re: JWT Tokens are NOT safe

#53

Post by lstamour »

edgyquant wrote: post #38
lstamour wrote: post #20

Earlier 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…

Aren’t JWT tokens only supposed to be good for 10-15 minutes? I know using flask-jwt you have to go out of your way to make them last longer than that and it isn’t recommended.

Expiry is just one of the fields you can set. Also if you’re curious about what’s inside a JWT, the next time you see one from an OAuth cookie perhaps, copy and paste it into a tool like https://JWT.ms run by Microsoft and it can show you the details. Commonly you want to load a JWKS (with multiple keys possible for easy revocation) to validate the signature, and check the iss (issuer of the JWT), aud (your app registration or audience of the token) and expiry date of the token. Oh and don’t forget to hard-code or reference the JWKS validation method so you don’t accidentally allow “none”. JWTs are not without their complexity, but the same could be said about maintaining secure session cookies and implementing 2FA yourself perhaps.

Re: JWT Tokens are NOT safe

#54

Post by jackson1442 »

0x5FC3 wrote: post #2

> JSON Web Tokens (JWT) are Dangerous for User Sessions—Here’s a Solution Actual title on the website. Edit: To watch clickbait work in real time, check OP's submit history.

@dang might want to check into that, OP seems to have a history of forcing submissions through.

Re: JWT Tokens are NOT safe

#55

Post by catamphetamine »

echelon wrote: post #39
catamphetamine wrote: post #28

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 th…

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.

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

Re: JWT Tokens are NOT safe

#56

Post by zamalek »

lstamour wrote: post #20
colesantiago wrote: post #3

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.

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 to address (Facebook, Twitter, etc.). If you really are the unfortunate soul trying to solve per-request authz, specifically at the scale that JWT was designed for, then I feel deeply sorry for you. For the 99%, i.e. the rest of us, 30min is just fine.

> You could use Redis for session data as pointed out with the random key in a cookie and delete the session when done to invalidate the cookie.

I'm not picking at your argument, honestly, I'm just pointing out the absurdity of authz without JWT (or similar) at scale. Redis is eventually consistent: what happens during a network partition?

Saying that the JWT expiry is a vulnerability is tilting at windmills.

> The general reason why folks don’t recommend JWTs is because it’s too easy to make mistakes in the validation logic.

Bravo, that's the real problem with JWT right there: it's too easy to misuse - especially when convenience or demanding customers enter the picture. It also has brain-dead specification opportunities like signature-free tokens.

Re: JWT Tokens are NOT safe

#57

Post by cameronh90 »

wokwokwok wrote: post #49
lstamour wrote: post #20

Earlier 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…

> The general reason why folks don’t recommend JWTs is because it’s too easy to make mistakes in the validation logic. That isn't why I don't recommend JWTs, and it's not why this article is not recommending JWTs. > Logout doesn’t really log you out! > Blocking users doesn’t immediately block them. > Could have stale data ^ JWTs fundamentally are not compatible with server-side authentication revocation. Your typical…

"database of revoked tokens...but you've just reimplemented server side session authentication"

There's one important difference between session authentication and JWT+revocation: the revocation list can be distributed asynchronously, whereas a session list needs at least read-after-write consistency.

It's a minor point for most use cases, but occasionally can be very significant.

Re: JWT Tokens are NOT safe

#59

Post by [deleted] »

wokwokwok wrote: post #49
lstamour wrote: post #20

Earlier 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…

> The general reason why folks don’t recommend JWTs is because it’s too easy to make mistakes in the validation logic. That isn't why I don't recommend JWTs, and it's not why this article is not recommending JWTs. > Logout doesn’t really log you out! > Blocking users doesn’t immediately block them. > Could have stale data ^ JWTs fundamentally are not compatible with server-side authentication revocation. Your typical…

[deleted]

Re: JWT Tokens are NOT safe

#60

Post by jfhufl »

RHSeeger wrote: post #4

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

Post reply on HN