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

Stop using JSON Web Tokens for user sessions

ds-security.com

Post reply on HN
Print view View original

121–130 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#121

Post by marius_k »

aidos wrote: post #81
alex_duf wrote: post #66

Earlier quoted context omitted.

>No, the application should be resistant to XSS instead Or we can admit that vulnerabilities are a likely possibility, despite all of our efforts. Therefore the most secure approach is to understand that limiting the impact of one vulnerability is a reasonable way of dealing with it. Otherwise you're suggesting running application code as root on the machine isn't a problem, since your application has no vulnerabilit…

I don’t understand the downvotes here. The application should be as resistant to xss as possible but things do sneak through and we should try to limit the damage in other layers. An example is that you could think you have no xss issues because you use react to do your rendering. Meanwhile you have a window.location = something_from_url which is just as capable of running js code if you’re not careful. Having the au…

Using xss one might target login form and steal username/password instead of a token. So I do not see argument here against jwt. Sure the xss will have to be more sofisticated(?)

Re: Stop using JSON Web Tokens for user sessions

#122

Post by klodolph »

acaloiar wrote: post #119
echelon wrote: post #107

Earlier quoted context omitted.

This article can't explain what it's trying to hit at! JWTs are stateless. JWTs reduce the distributed system complexity of having every microservice talk to an auth system in the flow of every request. But with that, there are tradeoffs. You cryptographically sign JWTs, then you don't have to check them against a session/authc/authz system. JWTs come with an expiry, and your systems statelessly trust them until they…

> A problem is that a user can't revoke a JWT by logging out or changing their password (unless you build extra infra to store the invalidations and fail closed) Applications should both invalidate JWTs on logout and validate JWTs haven't been revoked for every request. Yes, it's performance overhead and increases infrastructure demands. The problem is that people want JWTs to be both secure and fast. But the reality…

You can trade for complexity—you can use revocation lists if you want to revoke JWTs. The revocation list of unexpired but revoked JWTs will generally be much shorter than the list of valid JWTs. You can push these lists to your front-ends, if that’s where you authenticate requests.

Far from trivial to implement, but it gives you some amount of performance and security at the same time.

Re: Stop using JSON Web Tokens for user sessions

#123

Post by marcosdumay »

kaoD wrote: post #20

As a side question (or rather, what I expected the central point of the article to be instead): how are you supposed to actually use JWT? The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right? This means we need a short-lived access token (5 min or so?) so that sessions are revoked in a reasonable time if the token is stolen som…

This article confuses so many things that at first I thought it was making a completely different point. But let's go:

JWT is a format for tokens, it's not a choice between JWT and opaque tokens, as JWT can be opaque and transparent tokens can be in another format.

JWT just happens to be a format with good support in javascript. As a format, it's quite unremarkable, but as a standard it's a complete piece of shit where footguns abound. Anyway, it's easy to work with, while the alternatives tend to have the opposite features, being incredibly hard to work with, but easier to use correctly then wrongly.

Transparent tokens (the ones everybody knows how to verify) have the advantage over opaque tokens that you pointed out (they are easy to distribute). On the other hand, they are hard to revoke, so people tend to use short-lived ones. And yes, it's common for an application to have a long-lived opaque token that they only use in an authentication service to get short-lived transparent ones (that they use everywhere).

Anyway, the article is about the infrastructure for supporting JWT in javascript.

Re: Stop using JSON Web Tokens for user sessions

#124

Post by g-b-r »

kaoD wrote: post #20

As a side question (or rather, what I expected the central point of the article to be instead): how are you supposed to actually use JWT? The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right? This means we need a short-lived access token (5 min or so?) so that sessions are revoked in a reasonable time if the token is stolen som…

You're missing that JWT were a bad idea in the first place.

Oldish but still largely relevant: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

Re: Stop using JSON Web Tokens for user sessions

#125

Post by marcosdumay »

donatj wrote: post #71

The problem isn’t so much JWTs for auth, it’s just where you are storing them. The answer here is just to store your session JWTs in HttpOnly secure cookies, something we’ve done for years. It honesty simplifies everything anyway. The client has no need to see it or manipulate it. The client code just watches to see if its requests come back as unauthorized and boops you into the authorization process if you are. No…

> The answer here is just to store your session JWTs in HttpOnly secure cookies

And set CORS correctly (probably by not having anything in it), and deal with CSRF, and make sure you don't have any XSS issue.

It's definitively not insurmountable. But the XSS problem the article focus on still applies. (You shouldn't have any problem with XSS anyway, it's a solved problem that most of the times shouldn't even require thinking about it to keep it solved.)

Re: Stop using JSON Web Tokens for user sessions

#126

Post by g-b-r »

bob1029 wrote: post #51
had-rien wrote: post #18

I've been exploring best practices for session storage, and it seems like using HTTP-only cookies the only secure choice. However, I've hit a roadblock when trying to implement a login feature within an iframe, especially with Safari disabling cookie functionality in iframes. This has left me pondering alternatives for secure user authentication within iframes. Has anyone encountered a similar challenge or found a wo…

I had a problem with cookies on iOS/safari, so we reached for the last hope: url query args. Works flawlessly now. If you use an external identity provider, you can hypothetically avoid storing any cookies at all in first party terms. All you'd have would be 3rd party AAD tokens or whatever. The only reason we even need first party client state is because we want to allow each user simultaneous app sessions that have…

Keep in mind that urls end up in logs, that might well not be so well protected

Re: Stop using JSON Web Tokens for user sessions

#127

Post by acaloiar »

wokwokwok wrote: post #115
echelon wrote: post #107

Earlier quoted context omitted.

This article can't explain what it's trying to hit at! JWTs are stateless. JWTs reduce the distributed system complexity of having every microservice talk to an auth system in the flow of every request. But with that, there are tradeoffs. You cryptographically sign JWTs, then you don't have to check them against a session/authc/authz system. JWTs come with an expiry, and your systems statelessly trust them until they…

> A problem is that a user can't revoke a JWT. Bluntly, this. If you need need this functionality, for example, when you log out of a banking app... and if you've implemented token revocation, eg. by storing a list of 'revoked' tokens in a database somewhere when someone 'logs out' or gets banned. ...then, in most cases you should not be using JWT. Once you make your JWT stateful , by storing it in a database there i…

> Once you make your JWT stateful, by storing it in a database there is no reason to use JWT.

JWTs are a cryptographically sound means of conveying identity between systems, assuming the implementation doesn't allow `algorithm: none`. I'm genuinely curious why you perceive JWTs as useless when they're stateful. It's a common opinion, so I assume there's something to it. My best guess is that it stems from JWTs being "sold" as a stateless means of conveying identity. In which case, I think they fall short of that promise. I just don't equate that with useless. I'm using the word useless, which I interpreted your statement "no reason to use JWT" to mean, but feel free to correct me on that.

Re: Stop using JSON Web Tokens for user sessions

#128

Post by marcosdumay »

d-z-m wrote: post #78

> Modern web applications (so called single page applications) often utilize JSON Web tokens (JWTs) for session handling instead of cookies I had thought the main way JWTs are stored and transmitted in a web context is via Cookie/Set-Cookie? > This attack would not be possible with a cookie based session mechanism where attributes like HttpOnly would prevents injected JavaScript Code from accessing the JWTs. You can…

> What am I missing?

People using JS frontend frameworks to handle every single feature of the frontend, so that they have to let the cookie unprotected or store the token into a JS-only storage.

Re: Stop using JSON Web Tokens for user sessions

#129

Post by marcosdumay »

Maxion wrote: post #37
zaffe wrote: post #7

Ah, here we go again

It's still a bit weird how there's no universal gold standard way to handle authentication with websites. JWT is the closest there is, and there are still enough open ends with it for there to be as many ways to implement it as there are developers.

> there's no universal gold standard way to handle authentication with websites

Hum... HTTP has an entire authentication header.

There is also an entire set of standard practices to authenticate by cookies.

The only thing there isn't a standard is for handling authentication data with random code. As that's a pretty stupid thing to do.

Post reply on HN