JWT shouldn't be recommended for secure sessions or authentication

[shombo]

This isn't a bug with the course content, but more an issue with the project design. This link sums up the arguments pretty well.

[shombo]

No thoughts or comments on this? Security is mentioned in the course material a few times and many design decisions are discussed, but this one isn't really addressed. I feel as though the dangers of caching data client side should be acknowledged in the material, even if it's signed with a private key.

[Hinara]

What's the problem about JWT in this project ?
As we mentionned in the linked issue. The design of JWT token have no security flaw, so why do you want to remove JWT from this project ?
I feel as though the dangers of caching data client side should be acknowledged in the material, even if it's signed with a private key.
If that's the case do an issue about potential troubles with storing any token. And potentialy what you should do to avoid potential security flaws in your code.

[shombo]

The design of JWT token have no security flaw, so why do you want to remove JWT from this project ?

I didn't say it needed to be removed. It just isn't best practice and can be potentially misleading to newer developers.

do an issue about potential troubles with storing any token

That's what this issue is.

to avoid potential security flaws in your code.

Ok. Use some kind of session ID instead. This was also included in the link in the original issue.

[Hinara]

Misleading ? I don't understand in what. It's an authentification method as session token. With it's own pros and cons.
do an issue about potential troubles with storing any token That's what this issue is.
Where is it question about storage in your issue's title ?
Replacing it by session ID ? Why ? You just repeat that you don't want JWT token.
If it works without troubles, why would you swap to a session based system ?

[shombo]

Did you even read the link in the original issue post?

JWTs, by design, are meant to be used to store cached data. That's their only use case in the entire world. And that is exactly what you don't want to do if you're building a secure web service: a website, API, IoT device, or anything in between. From the moment you decide to start caching authentication and authorization data in a client-side token you've opened yourself up to security issues because you're trusting that the data you receive is correct and valid. And... If you don't trust that data (or want to revoke tokens when needed) then you need to build some sort of centralized revocation list which again: negates any benefit you might have gotten from a JWT in the first place. This goes back to the original security vs. speed argument: it is truly impossible to have a secure anything if you're using cached data to validate your user.

Not sure what's so hard to understand about this. But as a security researcher, I'd love for you to continue using this design pattern so that I can continue to collect bug bounties.

[Hinara]

I totally understand about this and it point out what I said there in the original post they are not easily revocable that's by design, and that's also in the design of https certificate.
So is HTTPS insecure ?
The trouble is the same as in real life, everything you sign cannot be easily revocate and that's normal !
If someone is able to copy your signature you can be totaly screwd up
But there is an advantage with stateless token (if you don't do revocation list) which is no centralisation
Once you are authentified even if the authentification server fall you're able to stay connected to make request. Which is not the case in centralized system.
So yes there is pros and cons. As always.

[rstruthers1]

@shombo - Just a suggestion - maybe make a pull request that illustrates doing the authentication a different way? That way, people can try it out on their own. Just a thought.

[shombo]

not easily revocable that's by design

That isn't really the issue. The issue is trusting cached user data provided by an untrusted source. EDIT: This is also part of the issue.

that's also in the design of https certificate.
So is HTTPS insecure ?

SSL certificates are easy enough to invalidate since they are validated by a third party. Additionally, they are not presented by the client. They are presented TO the client who is responsible for validating them with a CA.

If someone is able to copy your signature you can be totaly screwd up

Agreed. But why even allow this possibility? If you're using some session ID based auth instead, there's no untrusted data to sign and then implicitly trust. If your entire security model relies on protecting a single key, you're doing it wrong.

Once you are authentified even if the authentification server fall you're able to stay connected to make request.

This is not entirely precise. You don't need to be authenticated to produce a valid token. If you have the signing key, for example, you can then produce arbitrary tokens with arbitrary user data. This does not require actual authentication.

pros and cons

I haven't really seen a single pro so far for using untrusted cached user data as a valid authentication method. The only thing that approaches a pro is the stateless nature of them, but that is somewhat negated by the security vulnerability that it creates.

All I'm saying is that this isn't a totally secure authentication mechanism and that fact should at least be mentioned in the course material since security is addressed a couple of times. I understand why it was included in the course content and JWT is a great resource to be aware of, I just don't think that it's a great solution for authentication.

[shombo]

@rstruthers1

If I get a moment to implement this, I'll definitely submit a PR or at least present my own fork or something pending review of licensing and whatnot.

[Hinara]

This time you argument :)
Yes in the case of HTTPS it's the server who present a certificate in the more common cases (the client can also provide it' certificate to authentificate too)

But it does not differ too much in the way that in HTTPS case Client check based on CA as you mentionned which are the certificate that you choose to trust.

In the case of JWT as authentification token you choose to trust your authentification providers (which in most of the case is you)

But why even allow this possibility?
Because it offers a way to scale easily and potentially to have independent parts of your program.
It remove a SPOF (Single Point of failure)

negated by the security vulnerability that it creates.
It doesn't create security vulnerability it create potential security vulnerability. What I mean is that the error doesn't come from JWT, it comes from diffusion of the private key or token which can be in some case easy to achieve when your entire architecture is not secured (like using external scripts or XSS).

It's like having a door without lock inside your house. It's not a problem if your house is secure. But if it's unsecure it can become worse.

this isn't a totally secure authentication mechanism and that fact should at least be mentioned in the course material
Totally agree :)

[shombo]

It remove a SPOF (Single Point of failure)

If you don't consider a relying on a single key as a single point of failure (I do), sure. But then again, a well designed infrastructure will have fail over and redundancy mechanisms in place to prevent a single auth server from halting all operations. But that isn't even the point nor is it the design here. This project in monolithic and handles the authentication itself along with all of the other web server features, so by design, it is already a single point of failure. But I also believe that this part of the conversation is getting a bit beyond the scope of the course.

it create potential security vulnerability

You're relying on ultimately untrusted data. This, again, is not best practice for the entirety of authentication. And, as previously mentioned, they are irrevocable without implementing state, completely undermining the only legitimate argument for JWT.

It's like having a door without lock inside your house. It's not a problem if your house is secure. But if it's unsecure it can become worse.

What you're describing is a clear violation of defense in depth.

What I mean is that the error doesn't come from JWT

JWT, by itself, isn't a security concern. It's the misuse of JWT that is a security concern. If you're using it for session storage, you're using it incorrectly. This is indicated by the JWT authors themselves:

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

claims

Not session storage.

Here's another blog post from 3 years ago talking about this. This isn't a new argument.

[Hinara]

In case of authentification it's an identity claim like your ID Card is.
You're relying on ultimately untrusted data.
As said it's signed so "untrusted" ? Not really or you choose to trust something untrustworthy.
I agree with every other point