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

31–40 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#31

Post by sgift »

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.

Thanks. Really. This attitude of "if it's not perfect in face of some ridiculous scenario, it's useless" is why people go full "one password for everything, hanging on my screen". Each time someone falls into one of these absurd usability hazards there's a risk you loose them for everything security-related. And when something bad happens security professionals go "oh, but it is YOUR fault" .. yeah, thanks for nothing.

Your job is to solve problems. In the real world. For real people. Start doing it.

Re: Stop using JSON Web Tokens for user sessions

#33

Post by sseagull »

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…

I am no JWT expert, but I have found them useful for APIs rather than web apps accessed from the browser.

If the user is expected to use a programming language and hit the API many times a second, then even a short expiration and moderate refresh really help (might fully authenticate every 5 mins, which could be thousands of requests for some APIs).

Re: Stop using JSON Web Tokens for user sessions

#34

Post by Maxion »

duiker101 wrote: post #6
Maxion wrote: post #5

It's interesting how much of an upward hill battle it has been for me to argue that JWT tokens need to be stored in cookies rather than LocalStorage. In my latest project, the lead backend dev is convinced it is insecure to store the accessToken in a HTTPOnly cookie, and that it HAS to be stored in LocalStorage.

What was their argument?

Short lived access token, and long lived refresh token.

Upon access token refresh and login, refresh token is also rotated.

Refresh token expiry is tens of days, access token some hours.

Their opinion is that this is enough security.

IMO refresh token is vulnerable being stored in localStorage, and relying on users logging in and/or triggering token refresh to rotate refresh token is not really that great.

Re: Stop using JSON Web Tokens for user sessions

#35

Post by oopsthrowpass »

mewpmewp2 wrote: post #26
oopsthrowpass wrote: post #14

In my opinion there are 2 good approaches: If you really need to use JWT-s then store the refresh (just normal UUID looking token that is validated on the backend) token in a httpOnly cookie and JWT in local/session storage, use 10-15 minutes expiration and you are somewhat OK on logout= (the XSS is still maybe exploitable). On logout make sure to invalidate the refresh token. In my opinion a better way is to just us…

> I would not try to cram JWT-s into cookies they are too big, but maybe these days nobody cares about the extra bytes Why does the length matter compared to when they are sent with cookies or with a special header?

Yeah, fair point, maybe could get some wins if serving assets from same domain, but probably should use a CDN for that on different domain

Re: Stop using JSON Web Tokens for user sessions

#36

Post by kaoD »

sseagull wrote: post #33
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…

I am no JWT expert, but I have found them useful for APIs rather than web apps accessed from the browser. If the user is expected to use a programming language and hit the API many times a second, then even a short expiration and moderate refresh really help (might fully authenticate every 5 mins, which could be thousands of requests for some APIs).

But again, what's the difference between that and just having a moderately-long access token if you'll still be handing out access tokens for the lifetime of the refresh token?

Re: Stop using JSON Web Tokens for user sessions

#37

Post by Maxion »

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.

Re: Stop using JSON Web Tokens for user sessions

#38

Post by growse »

kaoD wrote: post #28
oopsthrowpass wrote: post #24

Earlier quoted context omitted.

Your refresh token does not need to be a JWT, it needs to be checked once in a blue moon and a server side round trip is OK

But I already pointed that out in my question. You didn't address my actual concern.

The access tokens go everywhere, to all services and are much more likely to be accidentally leaked / misappropriated. Refresh tokens are only used when talking (infrequently) to the access token minting service, so the scope of use is much much narrower.

Re: Stop using JSON Web Tokens for user sessions

#39

Post by madisp »

kahnclusions wrote: post #25
theropost wrote: post #10

Earlier quoted context omitted.

But aren't HTTPonly coookies stored in a SQLite db, and have no password attached in Firefox or Chrome?

Both cookies and localStorage are usually stored in an SQLite db… localStorage is totally accessible to any JavaScript running on the page, so your session can be completely hijacked and used later.

> HTTPOnly cookies are safe from XSS attacks.

Not completely true - the attacker can not exfiltrate the token but they can still make malicious requests right there in the victim's browser via XSS.

Re: Stop using JSON Web Tokens for user sessions

#40

Post by MPSimmons »

kaoD wrote: post #28
oopsthrowpass wrote: post #24

Earlier quoted context omitted.

Your refresh token does not need to be a JWT, it needs to be checked once in a blue moon and a server side round trip is OK

But I already pointed that out in my question. You didn't address my actual concern.

I'm not making any judgement calls here in terms of how things are _actually_ done, or what the _actual_ risk exposure is, but...

The design philosophy seems to be, use short-lived security credential A (the jwt) for all of your requests, which (again, _theoretically_) risks its exposure, and have a Security Credential B that you keep very secure, and use that to create new instances of Security Credential A.

If SC-A were a cookie and SC-B were kept in a hardware store, then I think this might be logical, but where they're both basically cookies, it seems kind of crazy to me, too. Maybe there are some details in how the actual storage of the cookies varies, but I think it's Hopium all the way down.

Post reply on HN