Live data from Hacker News

Stop using JSON Web Tokens for user sessions

ds-security.com

61–70 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#62

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?

No, because they are functional cookies, you don't need to ask for permission of those. I'm also deriving that you might be conflating the two things. JWT and cookies are two different things, but you can store JWTs in a cookie.

Re: Stop using JSON Web Tokens for user sessions

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

>and cookies are a no-go because of cookies directive

haha, what?!

this is not true.

Re: Stop using JSON Web Tokens for user sessions

#65
post #28

Earlier quoted context omitted.

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…

The point is JWTs can be validated independently on the server, no DB lookup is required. In distributed systems, that's the main benefit - they don't all need to talk to the auth server, just have a certificate that can be used to validate JWTs. This means they can't be practically invalidated per user though.

By contrast, refresh tokens go to the auth server that can do whatever checks are necessary to make sure the user is still allowed to use the service. This would typically incur DB lookups and require more complex auth logic than simply validating "yeah, this JWT is legit and still in-date".

Re: Stop using JSON Web Tokens for user sessions

#66

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

Re: Stop using JSON Web Tokens for user sessions

#67
post #17

TLDR store session things in cookies with httponly set. Basically nothing to do with jwts. More to do with xss

And set the SameSite attribute to strict to prevent CSRF

SameSite=strict is weird, because it means if someone follows a link to your we application they will be treated as logged out in the first page they interact with, then logged in on any subsequent navigations they make within your site.

Re: Stop using JSON Web Tokens for user sessions

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

Re: Stop using JSON Web Tokens for user sessions

#70
Terrible article. JWTs can be stored in cookies giving you httponly and samesite. If you have XSS vulnerability, what you store your JWTs or if you use JWT do sessions is the least of your concern. Every request to the domain still has cookies attached even with httponly set, that includes all the AJAX initiated requests. HTTPonly just prevents javascript from reading the cookie. It just prevents cookie theft.
Post reply on HN