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

81–90 of 115 posts

Re: JWT Tokens are NOT safe

#81

Post by lstamour »

rexer wrote: post #72
zamalek wrote: post #56

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

If the JWT is saved as a cookie, you can delete the cookie and the user’s browser is safely logged out. The threat model is that a user or third-party could intercept and reuse the JWT after logout. Sure. But then a malicious actor could re-use a JWT before you logout from the app also, which is a much larger risk. Malicious browser extensions for example could hide that they’re making clicks or taking actions in tabs just as they hide ads from you. Don’t get me wrong, extensions are sandboxed, but… any sandbox can be broken. In the end, whether or not your JWT was revoked at logout doesn’t affect the risk of malicious activity all that much as long as cookies behave the way they should. And as long as your JWT has appropriate expiry timestamps.

Re: JWT Tokens are NOT safe

#82

Post by yepitis »

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.

It is an ad. OP's recent post history are all Redis ads.

Re: JWT Tokens are NOT safe

#83

Post by hn_throwaway_99 »

There are viable solutions to the JWT revocation problem:

1. Make JWTs short-lived (10 mins or less), and use refresh tokens.

2. Note that for many apps, especially native mobile apps, a user rarely, of ever, logs out. And you only need to keep a revocation list around as long as it takes a token to expire, so your revocation list is often VERY small and thus can be kept in memory.

3. Thus, when a user logs out, they make a call to your server, and you store the user ID and timestamp - any JWTs issued before that time are considered invalid.

4. Write this data to postgres in a simple table. Then, using postgres NOTIFY functionality to update all your servers with the in-memory revocation list.

5. When checking a JWT, you validate the signature and check it against the revocation list.

This won't work in all cases if for some reason your revocation list is too big to fit in memory, but even then it's easy to extend it to a backing store if you outgrow this solution.

Re: JWT Tokens are NOT safe

#84

Post by echelon »

catamphetamine wrote: post #55
echelon wrote: post #39

Earlier quoted context omitted.

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.

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.

Re: JWT Tokens are NOT safe

#85

Post by lstamour »

cameronh90 wrote: post #57
wokwokwok wrote: post #49

Earlier quoted context omitted.

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

That said, the primary problem with distributed authentication and distributed revocation is either it slows down your processing as you wait for confirmation of new entries on the list, or you have a risk that actions might be allowed when another part of the system has tried to block them. We generally think of distributing authorization data asynchronously in the positive: adding a new user permission, rolling the list out to every authz server. But when you’re trying to block access immediately, it can be difficult.

Not to be negative—if your JWT expires after 15 minutes and your list updates every 10 seconds, you’ve improved your reaction time quite a bit for revocations.

Also, you can have an eventually consistent session store if you don’t mind that sometimes users might see a 403 they shouldn’t, if your app can cover it up such as by requesting content from a different region or waiting a bit. Similar to the idea of using a load balancer to pin sessions to particular servers.

Re: JWT Tokens are NOT safe

#86

Post by pabs3 »

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.

TLS client certs?

Re: JWT Tokens are NOT safe

#88

Post by kroltan »

rexer wrote: post #72
zamalek wrote: post #56

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

If you have an attacker that can obtain the token within 30min, it is reasonable to assume they might obtain the token immediately, and use it immediately too.

JWT expiration protects against situations where the token is stored (or made to be stored) somewhere improper and later used, not being pilfered during proper use.

As the article argues, it doesn't even protect against a malicious user using stale credentials to wreak havoc, such as a disgruntled employee that had access to the precious admin panel being fired.

Re: JWT Tokens are NOT safe

#89

Post by 0x5FC3 »

edgyquant wrote: post #87
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.

They posted this twice for some reason

The first post had the original title and it had 5 votes. Now this clickbait title and it blew up.

Re: JWT Tokens are NOT safe

#90

Post by koprulusector »

Anecdotally I see the source of security issues with auth[n|z] and/or JWT in general as lack of developer education or miseducation due to pervasive misinformation that so many (inexperienced)? coders post and share on YouTube, Reddit, and blogging sites.

The top examples of misconceptions I see being spread:

- JWTs are encrypted or secure in-and-of-themselves. You CAN encrypt JWTs, though I don’t think I’ve ever seen this, and generally speaking they won’t be encrypted, just signed. The best practice is to not store private information in a JWT. I’ve seen suggestions to include PII in JWTs since “cryptography” is used - incorrectly thinking this means encryption or not knowing the distinction between encrypting and signing

- Base64 encoding as encryption - Posts/videos explaining the HTTP Authorization header is “encrypted” using Base64. I have no idea where this comes from other than complete ignorance

- OAuth2 - I see lots of click-baity titles targeting beginner coders using variations of “How To Authenticate Your Users with [O]?Auth and JWT”, and the post/tutorial/video goes on to regularly conflate authentication (OIDC) and authorization (OAuth), and conflating use cases or distinction between sessions, cookies, JWTs

I am sorry for nit-picking, but the author says:

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

I am not sure I understand, is the author suggesting that JWTs are embedded in the URL? I’ve seen codes that are exchanged for a token embedded in URLs, but this one is new to me. I’ve only ever seen or used a JWT within the HTTP Auth header (eg Bearer ).

Additionally, the author says:

>It’s been found that many libraries that implement JWT have had many security issues over the years and even the spec itself had security issues. Even Auth0 itself, who promotes JWT got hit with an issue.

Uh, ok, I guess since software or specifications can sometimes have a bug, they can’t ever be patched or revised with a new version, so we shouldn’t ever bother using computers… seriously, what kind of argument is this?

Post reply on HN