What "verifying" means here is, - Decrypt the signature from the JWT which gives Hash(Header + Payload). Let's call this H1 - Compute a new hash by appending Header + Payload from the JWT. Let's call this H2 - Compare H1 and H2 and verify they match. So, technically it is "decrypting". Although, on a broader scope - I agree it would be more appropriate to call it "verifying" the signature.
Jwt is not about encryption, it as about signing. Only private key can be used for signing, public key is used to validate signature. I guess something wrong with your application, not jwt mechanism.
This video has no flaws from JWT, but instead a developer created flaw by allowing both HSA256 and RSA256. You only need one algo for jwt, and it should be specified as part of the verify. If done that way, when the new token is put into the token the verify token will fail
@emax75 actually he didn't create that problem he is actually using a website for learning purpose which is just like a mission to hack and punish the developer mistake
it's not just about roles, many servers store user id as sub to identify which user is making the requests. If you can change that you can essentially use someone else's account
I think it's important to note that this attack is only possible if the public key is indeed public or can somehow be extracted (using another attack). And to prevent this attack, you should make it so that the code responsible of validating the JWT does not allow the token itself to set the algorithm.
Symmetric encryption does not have 4:00 public key. Only secret key, or else it is not encryption, only a useless encoding transformation. The flaw 4:57 is that you treat the encryption key public. Not that the verification code is generic.
00:04 Understanding JWT and session authentication in web apps 01:46 Difference between session authentication and token authentication 03:35 Flawed JWT token validation leads to potential security loophole. 05:21 Decoding JWT Token obtained after logging in 07:14 Converting public key to PEM format and modifying algorithm for JWT tokens. 08:58 Exploiting JWT Tokens for key confusion attack 10:54 Modifying and resigning JWT token 12:49 Spoofing JWT token allows impersonation as an administrator Crafted by Merlin AI.
Hey teja im a very old viewer of yours and i remember you used to do some IoT projects it would be nice to see some latest videos about mixing IoT and AI to make some cool projects.❤
From all the videos I've been watching all these while, yours would be the only legit Informative ones... Man, you're supposed to be elsewhere... Hats off brotherman
The attack is pointless because the JWT is sent to the client as an HTTP-only cookie, preventing any modification by the client. Additionally, public keys are typically stored in environment variables (.env files), making them nearly impossible to access. Developers usually extract the user ID from the token in authentication middleware and query the database for user data. Thus, changing the payload offers no advantage since unauthorised users cannot access the system without authentication or the appropriate permissions.
as a backend dev you should know already tbh its just a frontend thing unless the backend is an open api with 0 permission checks every request requiring permissions those permissions need to be checked
@@dogefluvial7697 depending on what you said l won't face this vulnerability if I specified the premissions and used the honeypot so it's more simple than I expected
You should be safe from this kind of attack in almost all modern JWT libraries. Ignore the fool that say to check the permission before accessing an API route, they clearly either have not worked with JWT before to know how JWT is actually utilized to authorize users' actions or they completely missed the mark on the point of a JWT algorithm confusion attack.
what is the use of public key? data is encrypted and decrypted using a private key, and if you can encrypt data through public key, then it loses its meaning of security, or can you only check the authenticity of a signature through public key? PS and why not just use HS256
You should not confuse "RSA signing" and "RSA encryption". They both use the same underlying RSA algorithm but they serve different purposes. JWT use RSA in signing mode, not in encryption mode. In the RSA signing scheme, the private key is used to sign the message, the public key is used to verify the message. > PS and why not just use HS256 The reason you would prefer RS256 over HS256 is because HS256 uses HMAC which is a symmetric signing algorithm. This means that both signers and verifiers needs to know the same secret to respectively sign and verify. This means that you need to pre-share the secret between signer and verifiers (or come up with a key exchange procedure, which is probably a bad idea to implement yourself.) Honestly, I can't really see a reason to pick HS256 over RS256, but maybe someone will be able to elaborate on why you would want to use it.
@@jean-naymar602 for example, for the web, JWT is used to authenticate the user, if he makes a request to the site, then the cookies will contain JWT, which has information about the user, but still the JWT is always checked by the server, not the user, there is no point in first checking JWT on the client side (not safe) and then on the server side (takes 2 times longer)
@@jean-naymar602 ""I can't really see a reason to pick HS256 over RS256, but maybe someone " what you said is true reason why is performance (due to all exponentiation and modulus calculations) in ssh for example we gen tokens for our employees in HS265 cuz RS256 for our on-premise uses a lot of computation power .. and we run a lot of commands over ssh (during docker-compose for dev, terraform, when getting anything from the registry like npm or pip or docker, running a workflow/ephermial env to do some CI...etc etc) so we actually gen the key locally then copy past it to the server (all this within premise, so nothing really leaves the company network) and we use that on our own password manager (also on-premise)
I store JWTs in the database and use middleware to confirm the existence of the token with each subsequent request. If the token isn't in the database, it means we didn't assign it, so absolutely no access for that poor hacker 😆. He should really feel ashamed at this point!
As an absolute amateur just starting his journey with learning code and understanding how app functionality is done correctly and securely, would this be mitigated by using something like OAuth? Feel free to have a chuckle at my expense, I’m right at the beginning so could be talking nonsense but it would be great to understand this a bit better.
HTTP only cookies only prevent JavaScript from modifying the cookies. You can still generate a malicious cookie and replace it manually in the browser. Doesn't matter though. You just need to fake a request at the end of the day. If not browser, use a different client.
the JWKS endpoint is explicitly telling you the algorithm family ( kty ) and strength (alg or size of "n" - alg is optional but can be inferred by n). If any dev explicitly ignores this and trusts the incoming payload, you might as well not bother validating it at all. Auth vendors will NEVER sign JWTs using symmetrical algorithms, and you, as a receiver of JWT, should NEVER accept symmetrical algorithms. End of discussion!
3:20 i guess, you had interchanged those terms private key -> Encrypt, Public key -> Decrypt, it should be: Private key -> Decryption Public Key -> Encryption Correct me if I am wrong, overall the video was amazing, really learnt something new...
Asymmetric Encryption vs. Signing 1. Asymmetric Encryption: In traditional asymmetric encryption, you encrypt a message with a public key and decrypt it with a private key. This ensures confidentiality. 2. Digital Signatures: When you sign data (like a JWT), you create a hash of the data and then encrypt that hash with your private key. This process doesn’t provide confidentiality but instead ensures integrity and authenticity. Chat GPT
Server-side cookie management is the most secure, but JWT is not explained correctly in this video. Here, the key should be kept entirely in the backend and in the env. If possible, it should be started in the env when starting with the docker container, so that it can never be accessed from the outside or written physically. I recommend that you be informed about DevOps and Backend, otherwise the information you provided is incorrect.
Lol.... 🤣🤣🤣 I think you did't make any server before. Always every token has stored. When a user send request with the JWT everytime it check with the token which is created by the user. And JWT has not work with private public key.
What the heck is this logic at 4:11 ?? 😂 this logic totally defeats the purpose of private key People really need to learn what HMAC , RSA actually is and how jwt works HMAC encryption never ever uses a public key . If a server client follows HMAC then they share a secret key which is a private key which only the server and client knows and its not shared with anyone. Server use this private key to verify the token. The RSA encryption method uses public and private keys. Private key is kept secret in the server and server uses that private key to verify the token. No matter what encryption method you choose, private key will always be used to verify the token. If you are using public key to verify the token on server then 💀 Idk what this guy have hacked in this video 😂. Goodluck hacking other websites
You should probably re-learn what the RSA signing scheme is then... Private keys are used to sign, public keys are used to verify. Not the other way around. That's the whole point of signing: only a trusted party should be able to sign (thus they use the PRIVATE key), everybody should be able to verify the authenticity of the message (thus they use the PUBLIC key). bruh
@@jean-naymar602Yeah true, but hes still right about not being able to hack it like this if you dont go out of your way to make dumb decisions such as allow both hsa256 and rsa256 if someone attempts to change payload, and then they have to sign with the only key they have access to, the public key, it will no longer verify the new jwt when the backend attempts to verify it via the public key. Tldr rsa256 jwt public key cannot verify a jwt signed with the same public key If you allow both hsa256 and rsa256, thats the error, not some vulnerability in jwt.
@@jean-naymar602 When i say "server uses private key to VERIFY" it essentially means to sign in. There is only one job of the server i.e to sign in(as you used the word sign in) or some might use the word verify, authenticate which is essentially the same thing wrt server
You got the Asymmetric all wrong man, stop this madness ! You don't decrypt using a public key !!! Only the private key can decrypt the contents encrypted with a public key (if they are pairs) ! Plus, the only way to hack JWT is if it use the "none" **Algorithm** or weak Symmetric **Algorithm** keys ! To me, your scenario is out of this world.
@@crooked8168 you would normally be right about decrypting with the private key. However, in jwt what's done is SIGNING, not ENCRYPTION. That means that you may want many services to be able to "decrypt" (check the signature), but only one service may encrypt (sign). So, when signing, the private and public keys are opposite from when encrypting
2:24 Totally wrong information, We can nicely store sensitive data within a JWT and there's 0 possibility to decode this with knowing the secret, Just make sure keep your JWT secret strong.
You can absolutely decode a JWT. You just cannot change the JWT without having the correct private key that only the server knows and used to sign the JWT
This isn't a vulnerable in JWT but a skill issue in the dev's end.
Yeah, as he said at 4:42
3:37 public key cannot be used to decrypt its only used to verify the private signed that message..
What "verifying" means here is,
- Decrypt the signature from the JWT which gives Hash(Header + Payload). Let's call this H1
- Compute a new hash by appending Header + Payload from the JWT. Let's call this H2
- Compare H1 and H2 and verify they match.
So, technically it is "decrypting". Although, on a broader scope - I agree it would be more appropriate to call it "verifying" the signature.
Video starts at 4:56 if you already know what JWT is
Thanks a lot
Thx
Thanks
Jwt is not about encryption, it as about signing. Only private key can be used for signing, public key is used to validate signature. I guess something wrong with your application, not jwt mechanism.
This video has no flaws from JWT, but instead a developer created flaw by allowing both HSA256 and RSA256. You only need one algo for jwt, and it should be specified as part of the verify. If done that way, when the new token is put into the token the verify token will fail
That's what i thought, He created a problem and gave a solution xD
@emax75 actually he didn't create that problem he is actually using a website for learning purpose which is just like a mission to hack and punish the developer mistake
why it is fail ? Add I do not think developers use role parameter with JWT. Instead use database and check it is good idea.
This attack is useless if the server checks the DB for user roles which pretty much all of them do.
yasss.. when there are RBAC based actions.. but most of them rely on the token itself.. without querying db for every new req..
So just a validation can prevent it
@@Param3021 verify signature.. and only issue RS256 tokens..
it's not just about roles, many servers store user id as sub to identify which user is making the requests. If you can change that you can essentially use someone else's account
@@phaneendhraajaythota1025and why would you do that?
I think it's important to note that this attack is only possible if the public key is indeed public or can somehow be extracted (using another attack). And to prevent this attack, you should make it so that the code responsible of validating the JWT does not allow the token itself to set the algorithm.
Symmetric encryption does not have 4:00 public key. Only secret key, or else it is not encryption, only a useless encoding transformation.
The flaw 4:57 is that you treat the encryption key public. Not that the verification code is generic.
00:04 Understanding JWT and session authentication in web apps
01:46 Difference between session authentication and token authentication
03:35 Flawed JWT token validation leads to potential security loophole.
05:21 Decoding JWT Token obtained after logging in
07:14 Converting public key to PEM format and modifying algorithm for JWT tokens.
08:58 Exploiting JWT Tokens for key confusion attack
10:54 Modifying and resigning JWT token
12:49 Spoofing JWT token allows impersonation as an administrator
Crafted by Merlin AI.
Great video as always!
Bro i used to watch you years and years back pls uploaf regular videos about hacking and cracking
Very well explained. Congratulations!
Hey teja im a very old viewer of yours and i remember you used to do some IoT projects it would be nice to see some latest videos about mixing IoT and AI to make some cool projects.❤
Weird.
First of all why do you encrypt your token with assymetric key?
And what the heck is this logic at 4:05
Awesome buddy 🔥🔥🔥🔥〽️
From all the videos I've been watching all these while, yours would be the only legit Informative ones... Man, you're supposed to be elsewhere... Hats off brotherman
I’ve missed you so much & boom a video solving something I’ve always needed. This is why I love you so much! 🤣 Thanks, brother! 🫂
Why would any developer expose a jwt signing key?
The attack is pointless because the JWT is sent to the client as an HTTP-only cookie, preventing any modification by the client. Additionally, public keys are typically stored in environment variables (.env files), making them nearly impossible to access. Developers usually extract the user ID from the token in authentication middleware and query the database for user data. Thus, changing the payload offers no advantage since unauthorised users cannot access the system without authentication or the appropriate permissions.
Nice video , Loved the content
Awesome video! Actually learning what hacking really is
thanks brother
Very informative and useful video....but if you don't mind me saying that the background music is very distracting.
How can I as junior backend developer avoid this vulnerability 😢
as a backend dev you should know already tbh
its just a frontend thing unless the backend is an open api with 0 permission checks
every request requiring permissions those permissions need to be checked
@@dogefluvial7697 depending on what you said l won't face this vulnerability if I specified the premissions and used the honeypot so it's more simple than I expected
Prob just by using frameworks from 2024
You should be safe from this kind of attack in almost all modern JWT libraries. Ignore the fool that say to check the permission before accessing an API route, they clearly either have not worked with JWT before to know how JWT is actually utilized to authorize users' actions or they completely missed the mark on the point of a JWT algorithm confusion attack.
don't watch this channel
what is the use of public key? data is encrypted and decrypted using a private key, and if you can encrypt data through public key, then it loses its meaning of security, or can you only check the authenticity of a signature through public key?
PS and why not just use HS256
You should not confuse "RSA signing" and "RSA encryption". They both use the same underlying RSA algorithm but they serve different purposes.
JWT use RSA in signing mode, not in encryption mode.
In the RSA signing scheme, the private key is used to sign the message, the public key is used to verify the message.
> PS and why not just use HS256
The reason you would prefer RS256 over HS256 is because HS256 uses HMAC which is a symmetric signing algorithm. This means that both signers and verifiers needs to know the same secret to respectively sign and verify. This means that you need to pre-share the secret between signer and verifiers (or come up with a key exchange procedure, which is probably a bad idea to implement yourself.)
Honestly, I can't really see a reason to pick HS256 over RS256, but maybe someone will be able to elaborate on why you would want to use it.
@@jean-naymar602 for example, for the web, JWT is used to authenticate the user, if he makes a request to the site, then the cookies will contain JWT, which has information about the user, but still the JWT is always checked by the server, not the user, there is no point in first checking JWT on the client side (not safe) and then on the server side (takes 2 times longer)
@@jean-naymar602 ""I can't really see a reason to pick HS256 over RS256, but maybe someone " what you said is true
reason why is performance (due to all exponentiation and modulus calculations) in ssh for example we gen tokens for our employees in HS265 cuz RS256 for our on-premise uses a lot of computation power ..
and we run a lot of commands over ssh (during docker-compose for dev, terraform, when getting anything from the registry like npm or pip or docker, running a workflow/ephermial env to do some CI...etc etc)
so we actually gen the key locally then copy past it to the server (all this within premise, so nothing really leaves the company network) and we use that on our own password manager (also on-premise)
Jwt has 3 strategies.
1: Allow List
2: Deny List
3: JTI matcher.
This attacking is useless for allow list strategy.
I store JWTs in the database and use middleware to confirm the existence of the token with each subsequent request. If the token isn't in the database, it means we didn't assign it, so absolutely no access for that poor hacker 😆. He should really feel ashamed at this point!
Then why use JWT and not sessions?
@@mrlectus Absolutely! Sessions and cookies should be used for stateful sessions. Saving JWT token defeats their purpose.
> Storing JWTs in a database
So sessions with extra steps.
what the shit is going on your head. storing jwt in db???
Another victim of youtubers with their "why you should use Jwt" videos
wow bro thank you
I fix the issue by only verifying the signature if it's RS256 and deny the rest.
new settings. nice.
How do we know they are both asymmetric and symmetric in their code
As an absolute amateur just starting his journey with learning code and understanding how app functionality is done correctly and securely, would this be mitigated by using something like OAuth? Feel free to have a chuckle at my expense, I’m right at the beginning so could be talking nonsense but it would be great to understand this a bit better.
What is "algordem"? :D
where can i find the public key in the real websites?
@@karthikg_09 you cannot
I wonder how many websites have this kind of bug. Good luck
Bro what is more secure JWT or cookies session
In real scenario where to get that public key
its found on cokies or localstorage on client (browser)
Anywhere for sure 😹😹😹😹
❤❤
why do you want to implement HS256 at all? if you are a new dev you may want to because of simplicity but not a big task to convert to RSA256.
Dont we store tokens in HTTP only cookies whose value cannot be modified at all ?
HTTP only cookies only prevent JavaScript from modifying the cookies. You can still generate a malicious cookie and replace it manually in the browser.
Doesn't matter though. You just need to fake a request at the end of the day. If not browser, use a different client.
Is the attack useful if hs256 isn't configured? like in 4:05 if the elif statement isn't there, then will it work??
no
Furthermore, this attack will not work if you keep the key secret, as you should.
Please I need your help 😢
the JWKS endpoint is explicitly telling you the algorithm family ( kty ) and strength (alg or size of "n" - alg is optional but can be inferred by n). If any dev explicitly ignores this and trusts the incoming payload, you might as well not bother validating it at all.
Auth vendors will NEVER sign JWTs using symmetrical algorithms, and you, as a receiver of JWT, should NEVER accept symmetrical algorithms. End of discussion!
Vruh its 2024 and you are still using background music in video
3:20 i guess, you had interchanged those terms private key -> Encrypt, Public key -> Decrypt, it should be:
Private key -> Decryption
Public Key -> Encryption
Correct me if I am wrong, overall the video was amazing, really learnt something new...
Asymmetric Encryption vs. Signing
1. Asymmetric Encryption:
In traditional asymmetric encryption, you encrypt a message with a public key and decrypt it with a private key. This ensures confidentiality.
2. Digital Signatures:
When you sign data (like a JWT), you create a hash of the data and then encrypt that hash with your private key. This process doesn’t provide confidentiality but instead ensures integrity and authenticity.
Chat GPT
We store JWT in HTTP only cookies
Please remove him from shadow ban YT 😠
this makes no sense.. it does the same action in both if parts ...
Do you met with scam job recruters?
The Music is to Loud But great video
Bhai mai kam harami nahi hu mai phele token ko apne kud ke algorithm se pas karaya hai jise decode karna impossible hai.
Server-side cookie management is the most secure, but JWT is not explained correctly in this video. Here, the key should be kept entirely in the backend and in the env. If possible, it should be started in the env when starting with the docker container, so that it can never be accessed from the outside or written physically. I recommend that you be informed about DevOps and Backend, otherwise the information you provided is incorrect.
Algordim
Ahh yes "JWD" tokens
I need help
Why hell anyone use public key to sign the token😂
music ❌
content ✔
Pls don't play bg music
Every realm has rbac kid 🤣
I went to Ku rock chalk brother
FIRST :)
Lol.... 🤣🤣🤣
I think you did't make any server before. Always every token has stored. When a user send request with the JWT everytime it check with the token which is created by the user.
And JWT has not work with private public key.
Ffs learn to say algorithm!
You mean algordem?
What the heck is this logic at 4:11 ?? 😂 this logic totally defeats the purpose of private key
People really need to learn what HMAC , RSA actually is and how jwt works
HMAC encryption never ever uses a public key . If a server client follows HMAC then they share a secret key which is a private key which only the server and client knows and its not shared with anyone. Server use this private key to verify the token.
The RSA encryption method uses public and private keys. Private key is kept secret in the server and server uses that private key to verify the token.
No matter what encryption method you choose, private key will always be used to verify the token.
If you are using public key to verify the token on server then 💀
Idk what this guy have hacked in this video 😂. Goodluck hacking other websites
You should probably re-learn what the RSA signing scheme is then...
Private keys are used to sign, public keys are used to verify. Not the other way around.
That's the whole point of signing: only a trusted party should be able to sign (thus they use the PRIVATE key), everybody should be able to verify the authenticity of the message (thus they use the PUBLIC key).
bruh
@@jean-naymar602Yeah true, but hes still right about not being able to hack it like this if you dont go out of your way to make dumb decisions such as allow both hsa256 and rsa256
if someone attempts to change payload, and then they have to sign with the only key they have access to, the public key, it will no longer verify the new jwt when the backend attempts to verify it via the public key.
Tldr rsa256 jwt public key cannot verify a jwt signed with the same public key
If you allow both hsa256 and rsa256, thats the error, not some vulnerability in jwt.
@@jean-naymar602 When i say "server uses private key to VERIFY" it essentially means to sign in.
There is only one job of the server i.e to sign in(as you used the word sign in) or some might use the word verify, authenticate which is essentially the same thing wrt server
which stupid is using publickey for validating the jwt? Probably 13 years old developers do that.
in almost all real-scenario in production app. this is useless.
You got the Asymmetric all wrong man, stop this madness !
You don't decrypt using a public key !!! Only the private key can decrypt the contents encrypted with a public key (if they are pairs) !
Plus, the only way to hack JWT is if it use the "none" **Algorithm** or weak Symmetric **Algorithm** keys !
To me, your scenario is out of this world.
@@crooked8168 you would normally be right about decrypting with the private key.
However, in jwt what's done is SIGNING, not ENCRYPTION.
That means that you may want many services to be able to "decrypt" (check the signature), but only one service may encrypt (sign).
So, when signing, the private and public keys are opposite from when encrypting
Bhai please dont lower your standards with this kind of clickbait
2:24
Totally wrong information, We can nicely store sensitive data within a JWT and there's 0 possibility to decode this with knowing the secret, Just make sure keep your JWT secret strong.
Nope you can decode jwt without private key
That's not how JWT tokens work. Data you put is just base64 encoded. You can decode it and get the data.
You can absolutely decode a JWT. You just cannot change the JWT without having the correct private key that only the server knows and used to sign the JWT
So confident yet so wrong...
Somebody skipped the Encoding/Decoding classes
E
olgoridm😅
Bhai please dont lower your standards with this kind of clickbait