Hacker News Reader

Comment by afandian | Hacker News Reader

These failure modes have been used to criticise JWT over the years. But all of these errors are of the same level as "don't concatenate input strings into SQL strings" or "don't store passwords in plain text". That these errors are made says much, but not about the technology, IMHO.

View on HN

At least those are well known, no common web framework will save password in clear text, and there is comprehensive literature on how to use SQL and many well written ORMs that will make it very hard to shoot yourself in the foot.

For JWT, it's essentially promises of easy authentication process (rarely talking about the hard things like logout) spread like landmines over Medium and blogs, waiting to blow your foot and all your application with it.

Regarding logout, I think that's a fundamental issue with a stateless solution like JWTs. I mean, the whole point is that it is a self encapsulated token, so you don't have to go back to a central server to check if someone's login session is still valid. So how on earth do you invalidate it?

My boss wrote up this article on different ways to revoke JWTs: https://fusionauth.io/learn/expert-advice/tokens/revoking-jw... which examines a few interesting methods.

For many applications "slow" logouts are enough, i.e. basically do what is common in OAuth2 setups:

- Have a refresh token which is only usable with the (right) auth server and can only be used to generate new access tokens. As it's only usable with the auth server it's easy to revoke (it's kinda like a session cookie).

- Keep validity of access tokens short.

So by revoking the refresh token the logout will be done in at most highest_refresh_token_start_time + refresh_token_validity.

Through sadly any "faster" logout method on a distributed system is indeed quite complex. (Like propagating bloom filter headed blacklists of early revoked access tokens).

> For many applications "slow" logouts are enough

Why? I understand it might be acceptable for the next "Uber for Cats" SaaS but if you protect an account that is actually important, not being able to revoke an access key is an issue.

> Keep validity of access tokens short.

But then you are actually spamming your authentication service and it even starts to blur the distinction between access token and refresh token.

I understand that there is many specific use cases where JWT makes sense like when you have to delegate authentication but for other case which shouldn't be recommending it, not being able to properly logout is not a security practice we should have in 2020 and later.

What better tool do you suggest that can handle logout? It's 2020 and there are none.

OpenID Connect with JWT handles logout just fine if you really want it. Call the /oidc/tokeninfo to check the token is valid instead of verifying the signature offline. Of course this doesn't have the benefits of a decentralized token anymore. Can't have the cake and eat it too.

Doing regular, boring authentication using user/password just supports logout out of box.

So regular cookie session based auth? There are drawbacks such as managing session state on the server, and increased latency and cpu load, since you now have to have a db call on every action.

The argument is that this DB call, or something much like it, is inherently necessary to support logout. It's not something unnecessary that can be optimized away; getting rid of it entails losing functionality.

>rarely talking about the hard things like logout

Why hard?

You can always black list them

But then you have have make a database call to check the blacklist, so you might as well use sessions

I'm not sure about it, but what if Logout just removed token from client meanwhile "Logout from all devices" black lists token?

I tend to believe that it could be used by gmail, but it's just a guess

If you're blacklisting tokens at any point in your application, you then need to check this blacklist.

It goes into the same category as criticizing C's memory safety. The errors do say a lot about the tech being prone of misuse, and that's not really a good thing.

"don't concatenate input strings into SQL strings" is a pretty good comparison, because the rise of ORMs and APIs that make parameterized queries ergonomic has done probably 10 times as much to stop SQLi in practice as telling developers to sanitize their inputs ever did.

Agreed. But writing your own authentication frameworks are a virtually identical situation.

>sanitize their inputs ever did.

was even escaping input viable strategy?

if you escape thing, then your data in db is broken

parametrization seems like the only strategy out of those 2

some parts of a query cannot be parameterized, e.g. the column name for an 'order by' in many cases. So you have to do some kind of escaping, sanitation and concatenation.

While this solution isn't sexy, cannot it be just simple switch?

switch(int)

case 1: age

case 2: salary

I have yet to dream up/see a case where you can't puzzle literals together based on user-query parsing until you get your SQL query assembled.

Yes, unless the database has custom column names e.g. to add your own properties to some object. But that kind of schema is madness in other aspects as well...

If you're escaping/sanitizing to massage an input string until you can concatenate it into a SQL query, you're doing it wrong. Please don't.

An authentication protocol that has this many footguns and insecure defaults is probably just not a very good authentication protocol.

What would you suggest instead?

Irrelevant. If the application doesn't call the function to verify the user token, the application is insecure, it doesn't matter what protocol or token format is used.

To play devils advocate say the design by the library was that you could not read the jwt data without the library verifying it.

That goes away.

You ignore the fact that some protocols are easier to "do wrong" than others. The point other people are making is that JWT is one of those.

You're welcome to disagree but don't gloss over the fundamental point being made.

My response to that would be "Parse, don't validate" ( https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... ).

In other words "the function to verify the user token" should also return the payload data (e.g. the user ID, or whatever), and it should ideally be the only way to get that payload data. That way there's very little that can go wrong:

- If the verification function doesn't get called, then the application doesn't get its payload data (e.g. user ID), and hence can't be misusing that data.

- If the application is using the payload data, then it must have come from the verification function, and hence has been validated.

I'm adding JWTs to a system right now, and forcing this interface by encrypting all of the payloads. The only system with access to the decryption key will refuse to decrypt tokens which aren't signed, valid, non-expired, etc.

That's similar to saying that CRUD apps are bad because you can have SQL injection (as others have mentioned). Or that username/password is a "not very good authentication protocol" because some folks store passwords in a database in plaintext. Sure, the "none" algorithm is a footgun, but just make sure you don't allow it.

Maybe I'm talking my book (because I work for a company that sells software which generates JWTs) but I think it isn't that hard to securely validate them. It's just matching on JSON keys, mostly, and can be wrapped up in a library (like https://github.com/jwt/ruby-jwt).

I also wrote an article on how to build secure JWTs: https://fusionauth.io/learn/expert-advice/tokens/building-a-...

I guess the question is, where's the balance between the responsibility of the application developer vs the RFC authors? That's an interesting discussion to have, because I bet there is at least one valid use case for every one of the JWT RFC sections. (I've even heard of valid cases for the "none" algo, like if you are very concerned about performance and have other ways of validating your clients, such as mutual TLS certs.)

I've never written an RFC/standard, but I bet it isn't an easy task.

That's the thing, JWT is not an authentication protocol, that's just one (the most frequent) use-case of "transfering claims". The footguns, e.g. the choice of encrypted or not, or symmetric or asymmetric crypto, are a result of the flexbility required to cover the other use-cases. Maybe what's needed is a subset of JWT that's just for AuthN.

Ultimately, everyone has a first time working with some particular technology. If doing the right thing requires knowing specific coding patterns, there'll be a lot of cases where people do the wrong thing.

Of course you can improve the tooling but it's not the only conclusion.

If you don't read the docs, don't have the right mentoring, etc etc, your first go at anything is likely to be of low quality. Calibrate your confidence better, especially for anything security-related. Don't put it into production if you've only skimmed the docs (the mistakes we're talking about are novice mistakes).

Another conclusion you could draw is "use a built in security library not raw JWTs". There's just as much reason not to use a security library as there is not to use a SQL ORM.

But doesn't JWT sometime force people to use it in an insecure way because of how it is designed?

In a JavaScript browser app without backend server it is impossible to use it safe. The token must be visible to JavaScript which is unsafe by default.

You also need to store both the token and refresh token in your app which makes the refresh safety feature useless.

I still don't get JWT. It solves requesting an auth server all the time but when the token is stolen it can be used until it expires. This can be solved by setting the expiration very low but then the auth server is still requested all the time.

The only insecure-by-design authentication scheme is passing the user identifier through HTTP headers (it's unfortunately quite common). Headers are set by the web client, so any client can assume to be anyone.

Reply on news.ycombinator.com