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

Don't use JSON web tokens for sessions

cryto.net

Post reply on HN
Print view View original

31–40 of 153 posts

Re: Don't use JSON web tokens for sessions

#31

Post by joepie91_ »

chrisfosterelli wrote: post #20

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around t…

CSRF vulnerabilities are less severe than a stolen session. I've addressed the reason for that here: https://www.reddit.com/r/PHP/comments/4nwpvg/stop_using_jwt_...

> This is only true if you are using cookie headers to send the token (which is less common), not if you only use it for storage/retrieval of the token.

That's the normal mode of operation for cookies, and what you should assume the client to do.

> Lastly, he argues JSON web tokens are not easier to use, but then points out you need a dedicated Redis session store server to scale session authentications.

At a scale where you can't just store the sessions in the database you're already using (or on disk - see PHP), the added complexity of a single Redis server is negligible. Below that scale, you can just use your regular database, at no additional complexity cost.

> Managing sessions in mobile apps and command line apps is a huge pain compared to JWTs.

I've heard a few people claim this now, but none have been able to explain exactly how it's a "huge pain" or "more complex". Care to elaborate?

Re: Don't use JSON web tokens for sessions

#32

Post by joepie91_ »

pfooti wrote: post #9

What I do: I use tokens (rather than cookies), but I don't use JWT, for some of the reasons listed in the post, such as "can't expire" and "data goes stale". Instead, after authenticating a user, I issue a long piece of random (256 bits of random packed into a base64 string) to the user. I use the same string as a redis key whose value is the actual user ID of the authenticated user. That way the front end can pass t…

While that sounds fairly similar to most session implementations, I would recommend using a battle-tested implementation rather than using your own, if at all possible.

Re: Don't use JSON web tokens for sessions

#33

Post by joepie91_ »

EdSharkey wrote: post #16

So, if I'm reading the advice right, then ... * Using JWT for authorization, particularly for one-time use == GOOD * Using JWT to represent long-lived persistent session state == BAD and, always transmit your tokens in all directions over HTTPS. This seems like useful advice given all the reasons put forward. Do I understand correctly or did I miss anything?

That's pretty much a perfect summary, yeah.

Re: Don't use JSON web tokens for sessions

#34

Post by joepie91_ »

ubercore wrote: post #24

So, I've been approaching JWT as a "proof of login" essentially, to handle authentication across web, mobile apps. The only payload I use is relevant to identifying the user logged in. Session data would be handled by server-side code, though it's still early days for me so I haven't had a use for it yet. After reading this, I'm wondering if I'm misusing JWT, and should replace it for the use-case of authenticating A…

From the sounds of it, you're essentially using stateful JWT tokens. In that case, I'd recommend using a battle-tested session implementation for your stack of choice instead, if there is one - this rules out implementation errors or overlooked security issues on your end. Security can get pretty tricky.

The exact token scheme you use shouldn't matter for the client. As long as the client supports cookies in some way, it'll just treat it as a dumb blob of text - only the server needs to care about how to interpret the session token.

Re: Don't use JSON web tokens for sessions

#35

Post by vkjv »

fabian2k wrote: post #21

The one thing that I found scary when reading up on JWTs is that there is no way to revoke them. Of course you could check them against a list of revoked tokens on your server, but then your lose the stateless aspect. So the only remaining option to revoke a JWT is the nuclear option, invalidating all JWTs at once. This seemed like a rather large limitation to me. Related to this, the ability to encode further inform…

The nice thing is that you get quite a bit of middle ground to play with performance. Examples:

* Refresh TTLs that allow for some caching before hitting a DB (revoking). * Using a Bloom filter to revoke to limit the number of affected users, but also bound memory.

Re: Don't use JSON web tokens for sessions

#36

Post by SCHiM »

chrisfosterelli wrote: post #20

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around t…

I've tested many web applications, and around 80% of all applications I've tested contained an XSS of some sort or another, that number drops to around 40% if you only look at stored XSS & XSS in a get request. And to less than 10% when only looking at stored XSS.

Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing. Do NOT store sessions in anything other than cookies with the HttpOnly (and really, SecureFlag) flag set.

Using javascript to manage your sessions only the client side in any way is NOT secure.

Re: Don't use JSON web tokens for sessions

#37

Post by ubercore »

joepie91_ wrote: post #34
ubercore wrote: post #24

So, I've been approaching JWT as a "proof of login" essentially, to handle authentication across web, mobile apps. The only payload I use is relevant to identifying the user logged in. Session data would be handled by server-side code, though it's still early days for me so I haven't had a use for it yet. After reading this, I'm wondering if I'm misusing JWT, and should replace it for the use-case of authenticating A…

From the sounds of it, you're essentially using stateful JWT tokens. In that case, I'd recommend using a battle-tested session implementation for your stack of choice instead, if there is one - this rules out implementation errors or overlooked security issues on your end. Security can get pretty tricky. The exact token scheme you use shouldn't matter for the client. As long as the client supports cookies in some way…

I'm using actionhero for the backend. To be clear, I'm not concerned about _sessions_ so much as I'm concerned about authenticating all requests. I guess it's just still not clear to me based on the article and your feedback what the flaw is checking a valid JWT in the Authorization header to identify the user making the request? Other than the relative inability to invalidate sessions (ie, only hacky methods for achieving this)

Re: Don't use JSON web tokens for sessions

#38

Post by ZoFreX »

luhn wrote: post #12

This articles doesn't acknowledge where JWTs really shine: Authentication across a cloud of services, esp. a microservice architecture. JWTs allow a session to be shared across all of the services without any shared state.

Your architecture being microservices doesn't change the problems with using JWTs (or any "session" system based on signing things): you can't revoke them.

I am pretty confident being unable to revoke tokens will start to be a problem with any sufficiently large websites: you don't just need to scale in terms of traffic, but also in terms of people doing bad things.

If you're at this sort of scale, adding in another service that validates sessions is not a lot of work. Either your microservices that need authentication could have a library added to talk to this service, or you could put everything that needs auth behind something that validates the requests as they come in. Vulcand looks like it makes this easy (I haven't used it personally, but I've worked on a system that works similarly using an F5 device).

Sooner or later, you _will_ regret not being able to revoke sessions.

Re: Don't use JSON web tokens for sessions

#39

Post by merb » 

    You cannot invalidate JWT tokens
This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it.

    They are less secure
Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here.

    They are less secure
They take the same amount of storage than signed cookies, wuhu I use JWT so often and I NEVER exceeded the cookie limit, but I wouldn't store them there anyway.

JWT is as secure as any other solution and this article proves it since he isn't well informed, he just throws a bunch of stuff out and tries to be "an expert". Btw. every other solution is really dangerous as well, especially Cookies could be a total mess of security problems. The same could actually happen with Bearer Tokens.

My toughts are use the thing your most happy with and the thing you understand and the thing you can implement with code that is totally clear and especially code that is really really easy to understand. And actually JWT will mostly win this battle.

I've seen a lot of people just using Session Cookies from their Framework, but eventually have no idea about their risks, they have lots of CSRF all over the place, or using a too small ID or eventually the ID is not really random. Eventually this could happen with JWT too, tough. As seen by this guy, that he generates the JWT without any well known secure string. that could be changed.

Re: Don't use JSON web tokens for sessions

#40

Post by mwpmaybe »

chrisfosterelli wrote: post #20

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around t…

> In my opinion, it is MUCH easier to get a CSRF vulnerability

It's simple (though perhaps non-trivial) to protect against XSRF these days, especially if you're securing a JSON API, with:

1. the SameSite cookie option (Chrome-only for now)

2. double submit cookies (mentioned in the article)

3. filtering by the Accept request header, i.e. blacklist application/x-www-form-urlencoded, multipart/form-data, and text/plain, or whitelist application/json (protects against non-XHR, form-based attacks; only appropriate for JSON APIs)

4. CORS, i.e. disallow cross-origin requests, which is the default when no Access-Control-Allow-Origin response header is present (protects against XHR attacks; only appropriate for JSON APIs)

Post reply on HN