how to secure JWT Token which is getting decrypted without valid Secret?

[plush tangle]

Hello,

I recently came across that, some data which might can include sensitive information which is needed in the token or as an Token which is getting encrypted/signed using JWT, I noticed that on front-end, using some packages, the JWT Token is getting decoded/decrypted even without need of SECRET which was used to sign/encrypt the data which isn't a good thing if I think of Security & Safety of the data...

Even more, on Google too when I am searching, I tested 1 website where after pasting the Signed JWT Token, it's showing me the actual data decoded/decrypted without need of SECRET which I've signed/encrypted using SECRET.

I am not much experienced so I might not able to explain properly but I tried my best, but I want to understand is there any work-around or kinda solution to fix or resolve this above mentioned problem?

[civic patio]

Give this page a read: https://jwt.io/introduction/
The payload never gets encrypted. The payload becomes base64 URL-encoded and placed between two dots in the final JWT string.

[plush tangle]

Understood

[civic patio]

You can copy-paste any JWT string in the jwt.io Debugger to view its payload without having the correct secret.

[plush tangle]

so is there anyway to make it encrypt from being decoded/decrypted without secret or something??

[shadow ledge]

Please make an effort to use services like Google or Stack Overflow to search for your question before submitting it here. There is a very decent chance your problem has already been solved by someone else in some way.

Here are some search suggestions that could yield some results:

• https://google.com/search?q=what+are+http+sessions
• https://google.com/search?q=http+session+vs+jwt
• https://google.com/search?q=stateful+vs+stateless+authentication

[peak garden]

Yes. You put the JWT inside an http-only cookie.

[plush tangle]

but I can copy the JWT from Cookie Storage and decode, if I am not wrong Sir??

[fallow egret]

JWT is not used to encrypt data; it is used to securely authenticate or identify a user through a secret key. The only part of the token that is actually encrypted is the secret key. When a user sends a token to your backend, the system checks if the key used to generate the token matches the one you use. However, the payload is just base64.

In essence, JWT acts as a check to verify if the token sent is genuinely generated by your application. If you want to encrypt the payload—which, in my opinion, is unnecessary—you can use techniques like RSA or JWE. But why is encryption unnecessary? Because you shouldn't use JWT to pass sensitive data. Typically, JWT only contains useful information to verify the identity of the user, such as an ID or username.

In case you're wondering, "What if I modify the data and send it?"—that's where the secret key becomes crucial. If someone generates a token containing valid information from your application but uses a different key, your validator will identify it as invalid and deny access.

[fallow egret]

About that, yes, you can just "Simply copy" but the only one who can do that is the logged in user, because if it is set to HTTP only it becomes inaccessible via "Client"/Javascript/Document, so only the server has access to modify it for example.

And about the token, there are some forms of validation on it, 1 is the secret key, another is the expiration time for example.

[covert shuttle]

why not encrypt the token?

as another layer of " security "

[fallow egret]

In life we ​​can do whatever we want. 😃

[plush tangle]

Agreed, but if you go to Browser Console > Application > Cookies, then you can able to get the Token, right?? because in Remix I set the JWT Token in Cookie with HTTP Only, but still I can able to get it from Application Storage...

[plush tangle]

Yes, we don't even generally pass the sensitive data, but for Safer side, I would love to make it encrypt and secure it even it doesn't contain the sensitive data

[peak garden]

To embelish on this. The idea is, a JWT is like the key to a room. The key only fits the one lock, but what the key is, what it is made of and other information about the key can be obtained by the holder of the key, just by inspecting it. The concept of a JWT is like that, but the enhancement of the room key analogy with the JWT is, the lock will know, if the key was tampered with. And that is the whole idea behind JWTs. It is "signed" a certain way and if anything is changed in the JWT, that signing is no longer valid.

So, to answer your question @plush tangle "but I can copy the JWT from Cookie Storage and decode, if I am not wrong Sir??" Yes, as a human user getting the JWT, you could theoretically try to do something with it. But, as the human with the key, your chances of doing anything bad with it are slim to none. Where the "stealing" of the key is dangerous, is when machines can get the JWT and try to "fake" their way into a system with it. They don't want what is in the JWT, they just wish to try and reuse if for their own bad purposes. This is where http-only cookies come in. They stop (other) machines from getting access to your JWT.

And as a last note, you never want to store any personal data or mission critical information in any JWT. You store simple information for the user's access. The fact they have the JWT means, they have already been authenticated. The JWT itself should offer the access that user (or machine) needs.

[fallow egret]

If you really want to encrypt it, you can do something like this.

https://github.com/gabriel-logan/The-Rings-of-Power/blob/main/backend/src/lib/crypto.ts#L11

When you generate the token, you encrypt it and return it to the client. And in your Guard or Middleware where you verify the token, you decrypt it. This way, your JWT will no longer be visible. However, this encryption that I created creates some very "crazy" digits. So, after encrypting, I don't know, transform it into base64 before returning to the client and, logically, undo the base64 before decrypting in the middleware.

You can use for example the algorithm: "aes-256-ctr" and ivSize: 16, and in this case your key must have exactly 32 characters.

But I'll say it again, the whole issue here is not whether it's possible to see the data or not, if someone steals the token, it could be with WhatsApp encryption plus the Turing machine together, everything goes down... lol

[plush tangle]

Thank You for the help & explanation...

[plush tangle]

as I as looking into the code, encrypt function, you're having text it can be object but stringified?

[fallow egret]

String of course

[plush tangle]

okay!...

[plush tangle]

using this GitHub Code, you encrypt & decrypt the JWT token?

[fallow egret]

I did a kind of totally unnecessary workaround because I decided to use passportjs and needed this response on the client which was with another framework, so to not "leak" my token ugly in the URL I encrypted it.

This app is not serious, I made it as a challenge and left it there.