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

81–90 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#81

Post by aidos »

alex_duf wrote: post #66
SuperCuber wrote: post #19

This post is about XSS, not JWTs... > For security reasons, it is advisable for users to log out from a web application once they have completed their tasks No, the application should be resistant to XSS instead. Online banking and such are automatically logging out to prevent someone stepping away from the device and another person abusing the logged in session. > Frequently, when a Logout function is present in the…

>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 auth (whatever it is) in a http only cookie is one protection. Having it time limited is another. For some applications locking it to an ip address might make sense.

It’s not an either / or thing.

Re: Stop using JSON Web Tokens for user sessions

#82

Post by 7sidedmarble »

muldvarp wrote: post #47
kahnclusions wrote: post #25

Earlier quoted context omitted.

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.

> so all it takes is a little injected script If you can inject javascript, it's game over anyway. > HTTPOnly cookies are safe from XSS attacks. No, you can still do pretty much anything that cookie enables you to do. You just can't get the actual cookie string.

> If you can inject javascript, it's game over anyway.

Yeah, but as you pointed out the one thing you can't do is get the cookie. Having the auth token yourself as the attacker is a way different story then just having XSS vulnerabilities. You can still "do" a lot, but you still have to get another user with the token you want to interact with the page with your XSS to "do" what you want.

Re: Stop using JSON Web Tokens for user sessions

#83

Post by embik »

andybak wrote: post #15
embik wrote: post #11

It would be helpful if the post not only told you what to _not_ do (especially when it is a frequently done thing) but offered any sort of alternative.

Cookie based session logins like everyone used to use?

Not everyone can look back at a 10 year long career in the industry to draw inspiration from. Especially for junior engineers, pointing out alternatives (that feel obvious to you) would be important.

Re: Stop using JSON Web Tokens for user sessions

#84

Post by d-z-m »

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.

Not sure if I could bring myself to call JWT for website authentication the "gold standard". I'd give the title to HTTP Basic Auth first.

Re: Stop using JSON Web Tokens for user sessions

#85

Post by jongjong »

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.

It depends on the use case. For example, if your app uses WebSockets for all its data, authentication and access control and only uses HTTP for static files, you may not want the JWT to be sent to the server as a cookie with each HTTP request as it would be wasteful so localStorage may be more appropriate.

However, with cookies, you have to be careful with the SameSite flag and also be mindful that some older browsers may not support it and so it can be tricky to fully restrict where the cookie will be sent in all scenarios.

Re: Stop using JSON Web Tokens for user sessions

#86

Post by [deleted] »

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…

[deleted]

Re: Stop using JSON Web Tokens for user sessions

#87

Post by icambron »

Ironlink wrote: post #55
isodev wrote: post #9

Earlier quoted context omitted.

I'm curious what were their reasons - it's hard to imagine how localStorage would be "more secure" than http only cookies. It's not a zero-sum situation. There are risks and vulnerabilities in every approach, that's why we as web devs take advantage of multiple safeguards to ensure safety when sensitive information is to be transmitted over the wire.

My best guess is that they are thinking of CSRF. With cookies, requests automatically carry the token, whereas with local storage you need to explicitly add the token. However, CORS does a lot to improve this situation. I note that CORS allows posting form data without pre-flight, but it is not immediately clear to me if posting a form cross domain will send cookies.

This is what the SameSite setting on the cookie controls

Re: Stop using JSON Web Tokens for user sessions

#88

Post by d-z-m »

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?

As I understand it, de-centralized verification isn't a necessary characteristic of a JWT. There are token constructions that make that a priority, however[0].

[0]: https://www.biscuitsec.org/

Re: Stop using JSON Web Tokens for user sessions

#89

Post by andybak »

sam_lowry_ wrote: post #59
andybak wrote: post #15

Earlier quoted context omitted.

Cookie based session logins like everyone used to use?

I work for ab EU government, and cookies are a no-go because of cookies directive, so we use JWT and auth the javscript engine, not the browser. This leads to a multitude if problems, but who cares?

This makes no sense. The law didn't specify cookies specifically, it is agnostic about the technical implemention, surely?

Is this a clueless manager thing?

Post reply on HN