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

71–80 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#71

Post by donatj »

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 need to manually append any sort of auth onto any request. The cookie jar does it for you automatically. It’s really how you should be doing it already.

Only real hitch is you can’t cross domain barriers, but that’s not insurmountable. Couple ways to handle it, we generally prefer a little handshake process and a separate JWT per domain. That said, we try to keep everything on subdomains and set the cookie for .example.com

Re: Stop using JSON Web Tokens for user sessions

#72

Post by plagiarist »

simonw wrote: post #68

"For security reasons, it is advisable for users to log out from a web application once they have completed their tasks." Isn't that a net reduction in security? Users are more vulnerable to phishing attacks if you've taught them to constantly login and logout of the applications they use. Much better to have them sign in infrequently but more securely using 2FA.

I think I am far less likely to be successfully phished (compared to earlier internet) now that I have a password manager programmatically checking domains to choose credentials. I wouldn't think everyone is doing that, but maybe iOS and Android have kinda nudged the majority to use password managers?

Re: Stop using JSON Web Tokens for user sessions

#73

Post by uticus »

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…

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

No. Focus on “token” instead of “JWT.” JWT is just a standard.

Re: Stop using JSON Web Tokens for user sessions

#74

Post by Rexxar »

sam_lowry_ wrote: post #60
RedShift1 wrote: post #32

Earlier quoted context omitted.

You do NOT need a cookie banner to store a session ID or a JWT.

because these are not cookies, right?

The law has never been about cookies themself but about tracking user and asking their consent for selling/sharing their identifying data for things unrelated to the displayed purpose of the site.

Re: Stop using JSON Web Tokens for user sessions

#75

Post by nijave »

airza wrote: post #21

Oh fuck off. This energy and thinking inside the appsec community (of which i am a working member) is the reason the local _pizza company_ feels the need to have a 12 hour timeout on my mobile phone. Just implement a decent content security policy and then you can have the best of both worlds: stateless backend without having the (incredibly minor) risk of having your jwt token stole on my goddamn pizza website.

Meanwhile, my Gmail linked to multiple other accounts is logged in to for months at a time.

Re: Stop using JSON Web Tokens for user sessions

#76

Post by uticus »

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…

Agreed. If security needs to extend past domain, you are not using the web in the way the web supports.

I appreciate interesting solutions that bend the rules of the underlying technology, but (1) the web needs to be treated as if it is what it actually is, and (2) papering over the parts that cause pain is not helping anything.

Re: Stop using JSON Web Tokens for user sessions

#77

Post by simonw »

plagiarist wrote: post #72
simonw wrote: post #68

"For security reasons, it is advisable for users to log out from a web application once they have completed their tasks." Isn't that a net reduction in security? Users are more vulnerable to phishing attacks if you've taught them to constantly login and logout of the applications they use. Much better to have them sign in infrequently but more securely using 2FA.

I think I am far less likely to be successfully phished (compared to earlier internet) now that I have a password manager programmatically checking domains to choose credentials. I wouldn't think everyone is doing that, but maybe iOS and Android have kinda nudged the majority to use password managers?

I agree that password managers are a huge win from a security perspective, but sadly I'm willing to bet they are still used by a tiny minority of people, even now they are built in to common operating systems.

Re: Stop using JSON Web Tokens for user sessions

#78

Post by d-z-m »

> 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 put the JWT inside the HttpOnly cookie, right? What am I missing?

Re: Stop using JSON Web Tokens for user sessions

#79

Post by vulcanash999 »

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 could use the access token for each request. The advantage is that it is a simpler approach, and does away with the 5-minutes restriction you refer to, as the logout/invalidation would be immediate and not in 0-X minutes where X is the access token life in minutes. The disadvantage is that serving each request will involve making a round-trip with the auth service. This means at the minimum a DB read for every request, but could also mean a call to a separate, (possibly a third-party) auth microservice, and with possible fraud-detection measures each request. Depending on your use-case, you can drastically reduce the number of calls made to the auth server/database by using JWTs (or any other "algorithmically verifiable" token). This improves performance and enables architectures where for example you have a single auth server globally but multiple "functional" edge servers close to your users to serve out requests as soon as possible.
Post reply on HN