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

Stop Using JWTs

gist.github.com

Post reply on HN
Print view View original

191–200 of 335 posts

Re: Stop Using JWTs

#191

Post by tasuki »

tracker1 wrote: post #116
hparadiz wrote: post #52

Earlier quoted context omitted.

You should not be using them for user contexts at all. The cookie should be the session token and the sessions should be stored on the server side where you can simply delete them and the user's login becomes invalid. Using JWTs for this use case is just plain wrong.

I disagree with you and the article on this... I thought that was pretty clear. You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.

> You can use a revocation list with JWT if necessary

Yes and let me just add that in many cases the use case is such that a revocation list is not even needed and then JWTs are actually stateless and it's a small win for everyone.

Re: Stop Using JWTs

#192

Post by nish__ »

agwa wrote: post #37
nine_k wrote: post #19

Earlier quoted context omitted.

> if you have to check an identifier for revocation on every request you could just use an opaque session ID and look that up on every request instead! One reason could be the size. A revocation list only needs to keep session IDs of recently logged-out sessions, for which the token's TTL hasn't yet expired. It may be a much smaller list than a list of every active session. Also, a JWT (or a Macaroon, etc) can store…

As someone who operates a PostgreSQL database containing 27 billion SSL certificates, each 1-2kb each, with a bunch of secondary indexes that get inserted in random order, I find it pretty incredible that people see the need to optimize their session database. At what scale does the size of the session database actually matter? Those stateless tokens may be "unforgeable", but they are replayable, and if you're not mi…

27 billion? Do you work at AWS?

Re: Stop Using JWTs

#193

Post by jeswin »

tptacek wrote: post #144
jeswin wrote: post #139

Earlier quoted context omitted.

> utility is of a standard that creates affordances for the insecure defaults You could make the same argument about Cookies. > as opposed to just designing it right from the beginning And generally, it's quite difficult to design it right from the beginning because one would often start with the wrong assumptions. Most standards evolve, and it should be acceptable.

No, that doesn't square up. It's like arguing "you could say the same thing about TCP, because it allows you to build JWTs, which are a bad protocol".

Not the same. HttpOnly/Secure cookies were added much later and was not the default. They should have been inaccessible to JS by default from the beginning, and this policy has been a source of countless attacks.

Re: Stop Using JWTs

#194

Post by locknitpicker »

solatic wrote: post #3

Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication. edit: I read some of the linked stuff, e.g. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Please, if JWTs are such a horrifically insecure standard, go ahead and publish your means for hacking AWS STS's AssumeRoleWithWebIdentity , or don't publish and just exploit it by launchin…

> Necessary qualifier: for browser-based user sessions.

True. Still the article can't really make any case, other than pointing misuses and throwing a few baseless assertions.

In fact, it surprised me to see such an article featuring so many upvotes.

The primary use for JWTs is to allow resource owners to perform stateless JWT validation,and then be able to trust a JWT's payload to perform authentication and authorization. This doesn't mean what the blogger think it means. These processes become stateless because the resource owner does not need to perform any inline request to be able to tell whether the JWT can be accepted or not. Meaning:

- The JWT is signed and/or encrypted, and the resource owner can use it's JSON Web Key set verify and/or decrypt it.

- the JWT, once deemed valid, includes metadata that helps the resource server determine if the JWT should still be accepted. This includes timestamps of when it was issued at and when it expires, a JWT ID to check a revocation list, and even a few user claims such as user id, audiences, scope, etc. A resource owner does not need to perform any request inline to perform those checks. The revocation list needs to be kept fresh but it can be refreshed as a background task. At most, if the JWT is expected to be single-use, the resource owner is able to run the nonce/JWT ID through a denylist.

- one of the primary values of JWTs is performance. For the vast majority of usecases, the whole verification&validation flow is stateless. This means no outbound request is needed to execute authentication and authorization checks. Instead of plowing through something between 20-100ms of latency to handle auth in each request, the whole flow takes less than 1ms.

I don't think the blogger fully grasps this nuance. Outright asserting that JWTs introduce performance issues completely erodes any trust that the blogger has a solid grasp on the subject.

Re: Stop Using JWTs

#195

Post by hasley »

jongjong wrote: post #185
chuckadams wrote: post #84

Earlier quoted context omitted.

A revocation list defeats the purpose of JWTs. If you find yourself needing one, JWTs were probably the wrong choice to begin with.

Not really. Being able to verify a user's signed identity immediately without having to do any database or memory store lookup first is valuable in itself. With session IDs, anyone can spam/DDoS your system much more easily; they don't even need to be authenticated to waste your computing resources as they can send plausible-looking session IDs and your system will waste a ton of resources querying your session store…

Can't a system be DDoS'ed with wrongly signed JWTs as well?

Is signature checking (much) cheaper than finding an opaque session ID in a database?

Re: Stop Using JWTs

#196

Post by RagingCactus »

jongjong wrote: post #183
robertlagrant wrote: post #61

Earlier quoted context omitted.

> While common JWT libraries have now mostly got their stuff together, this has not always been the case. There were plenty of libraries accepting the "none" algorithm [1] or allowing attackers to forge tokens by using a public key as a shared secret [2]. This is the direct result of the complexity criticized in the linked blog post. I'm a bit surprised at this. These are extremely simple to solve - the first time I…

The people who are upset about JWTs probably got burned by trying to use them in a weird way. Some people try to store sensitive data inside JWTs... WTF, the idea would never have entered my mind! Sensitive data should stay on your server. Encrypted or not! JWTs are supposed to be signed, not encrypted! You shouldn't even think to put sensitive info in there. Also, WTF is wrong with people who accepted algorithm "non…

> Also, WTF is wrong with people who accepted algorithm "none."

They dared to use the default validation function of their JWT library. They did not choose to accept "none".

And the library authors implemented it because it's in the spec. It doesn't excuse that the default was to accept "none", but it is an explanation and in my opinion a valid critique of the standard.

Re: Stop Using JWTs

#197

Post by stavros »

figassis wrote: post #131
dchest wrote: post #107

Earlier quoted context omitted.

WTF: > Each user has a secret: Stored securely in the database. > Stateless Validation: The core validation remains stateless. We only need to consult the database for the user's secret, which we'd likely do anyway for authorization checks. Is "stateless" the same as "serverless" now? Is author's brain stateless?

A JWT is usually signed, with a secret you keep in your app. The statelessness of JWT is that it contains all the information you need to verify it. You do not need to ask a db if the token is there and valid. Storing a user's secret, the same way you store your applications secret does not make it more or less stateless. In since you now have 2 layers of protection, you don't actually need to verify agains a user's…

If I need a database query to validate the token, it's not stateless.

Re: Stop Using JWTs

#198

Post by locknitpicker »

RagingCactus wrote: post #16
solatic wrote: post #3

Necessary qualifier: for browser-based user sessions. Plenty of good uses for JWTs for service-to-service communication. edit: I read some of the linked stuff, e.g. https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Please, if JWTs are such a horrifically insecure standard, go ahead and publish your means for hacking AWS STS's AssumeRoleWithWebIdentity , or don't publish and just exploit it by launchin…

> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…

> All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has not always been the case.

This is a red herring. Applied cryptography was never considered an easy subject in software engineering circles. Neither was algorithms and data structures. Yet, it's still a basic tool, and developers are still expected to understand things such as why some maps allow reads in constant time while others require log time.

Some libraries being buggy never was an argument against using libraries. And do you expect your single-purpose code not to be?

I think we are seeing in this thread a knee-jerk reaction against perceived complexity. Yet, if you sit down and compare JWTs with alternatives and list all features along with pros and cons, you'd be hard-pressed to even try to put together a case for JWTs being bad.

Re: Stop Using JWTs

#199

Post by stavros »

tracker1 wrote: post #116
hparadiz wrote: post #52

Earlier quoted context omitted.

You should not be using them for user contexts at all. The cookie should be the session token and the sessions should be stored on the server side where you can simply delete them and the user's login becomes invalid. Using JWTs for this use case is just plain wrong.

I disagree with you and the article on this... I thought that was pretty clear. You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.

But in that case you're just using sessions, and the JWT is a microoptimization to avoid hitting the DB every request.

Re: Stop Using JWTs

#200

Post by jongjong »

hasley wrote: post #195
jongjong wrote: post #185

Earlier quoted context omitted.

Not really. Being able to verify a user's signed identity immediately without having to do any database or memory store lookup first is valuable in itself. With session IDs, anyone can spam/DDoS your system much more easily; they don't even need to be authenticated to waste your computing resources as they can send plausible-looking session IDs and your system will waste a ton of resources querying your session store…

Can't a system be DDoS'ed with wrongly signed JWTs as well? Is signature checking (much) cheaper than finding an opaque session ID in a database?

Yes but it only impacts your stateless app servers which are easier to scale. Your backend services/stores are protected and not affected by the attack.
Post reply on HN