This isn't a vulnerable in JWT but a skill issue in the dev's end.
@maxbd2618Ай бұрын
Yeah, as he said at 4:42
@adesopekingsley9967Ай бұрын
3:37 public key cannot be used to decrypt its only used to verify the private signed that message..
@TechRaj156Ай бұрын
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.
@GrantGryczanАй бұрын
Video starts at 4:56 if you already know what JWT is
@sadatarefinrafatАй бұрын
Thanks a lot
@ankurdahiya1354Ай бұрын
Thx
@anshu4190Ай бұрын
Thanks
@srikanthpolineniАй бұрын
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.
@ISoawАй бұрын
This attack is useless if the server checks the DB for user roles which pretty much all of them do.
@phaneendhraajaythota1025Ай бұрын
yasss.. when there are RBAC based actions.. but most of them rely on the token itself.. without querying db for every new req..
@Param3021Ай бұрын
So just a validation can prevent it
@phaneendhraajaythota1025Ай бұрын
@@Param3021 verify signature.. and only issue RS256 tokens..
@yogeshdevaggarwalАй бұрын
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
@JoeRomano-s8gАй бұрын
@@phaneendhraajaythota1025and why would you do that?
@dustingodin5323Ай бұрын
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
@emax7527 күн бұрын
That's what i thought, He created a problem and gave a solution xD
@MuhammadAbdullah-o2o2n22 күн бұрын
@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
@indramal21 күн бұрын
why it is fail ? Add I do not think developers use role parameter with JWT. Instead use database and check it is good idea.
@parlor3115Ай бұрын
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.
@DevRaj-y9pАй бұрын
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
@PeterVerhasАй бұрын
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.
@i_am_ahackerАй бұрын
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.
@begthere3839Ай бұрын
Bro i used to watch you years and years back pls uploaf regular videos about hacking and cracking
@SanchklycАй бұрын
Weird. First of all why do you encrypt your token with assymetric key? And what the heck is this logic at 4:05
@shirshgupta1817Ай бұрын
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.❤
@pushparajmehta16 күн бұрын
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.
@robslaney3729Ай бұрын
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!
@emililie2244Ай бұрын
Very well explained. Congratulations!
@cr_crypticАй бұрын
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! 🫂
@vinaykumar-qe4zx20 күн бұрын
Very informative and useful video....but if you don't mind me saying that the background music is very distracting.
@timur.shhhhhАй бұрын
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
@jean-naymar602Ай бұрын
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.
@timur.shhhhhАй бұрын
@@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)
@GreatTaiwanАй бұрын
@@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)
@et_matrixАй бұрын
Jwt has 3 strategies. 1: Allow List 2: Deny List 3: JTI matcher. This attacking is useless for allow list strategy.
@HavishGАй бұрын
Awesome video! Actually learning what hacking really is
@MirzyeАй бұрын
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!
@mrlectusАй бұрын
Then why use JWT and not sessions?
@TheERPGuyАй бұрын
@@mrlectus Absolutely! Sessions and cookies should be used for stateful sessions. Saving JWT token defeats their purpose.
@destroyer-medic5073Ай бұрын
> Storing JWTs in a database So sessions with extra steps.
@tiosatria9919Ай бұрын
what the shit is going on your head. storing jwt in db???
@stefano_schmidtАй бұрын
Another victim of youtubers with their "why you should use Jwt" videos
@briangicharu289925 күн бұрын
Why would any developer expose a jwt signing key?
@amxdai4568Ай бұрын
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.
@berkaydemirkol620425 күн бұрын
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.
@PatrickValle-b8fАй бұрын
I fix the issue by only verifying the signature if it's RS256 and deny the rest.
@utensilapparatus8692Ай бұрын
new settings. nice.
@mohmmedelgamal969Ай бұрын
How can I as junior backend developer avoid this vulnerability 😢
@dogefluvial7697Ай бұрын
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
@mohmmedelgamal969Ай бұрын
@@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
@viIdenАй бұрын
Prob just by using frameworks from 2024
@destroyer-medic5073Ай бұрын
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.
@KubkochanАй бұрын
don't watch this channel
@ZaeemtechnicalАй бұрын
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...
@elitetester-ql8xgАй бұрын
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
@KaluPrince-rj4mqАй бұрын
Please I need your help 😢
@phaneendhraajaythota1025Ай бұрын
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.
@ebukaumeАй бұрын
I wonder how many websites have this kind of bug. Good luck
@jalladcom-sq1wkАй бұрын
@karthikg_09Ай бұрын
where can i find the public key in the real websites?
@artistry791918 күн бұрын
@@karthikg_09 you cannot
@Go4adv3ntureАй бұрын
How do we know they are both asymmetric and symmetric in their code
@MAK_007Ай бұрын
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
@jean-naymar602Ай бұрын
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
@dustingodin5323Ай бұрын
@@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.
@MAK_007Ай бұрын
@@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
@joshuagiftsoni4062Ай бұрын
Please remove him from shadow ban YT 😠
@adwaidh9690Ай бұрын
Is the attack useful if hs256 isn't configured? like in 4:05 if the elif statement isn't there, then will it work??
@ameval-sessions4213Ай бұрын
no
@PeterVerhasАй бұрын
Furthermore, this attack will not work if you keep the key secret, as you should.
@overratedpancake9034Ай бұрын
Great video as always!
@lilham9044Ай бұрын
The Music is to Loud But great video
@AwanUsman-ru5uhАй бұрын
We store JWT in HTTP only cookies
@hiteshks11Ай бұрын
Nice video , Loved the content
@flutter-fm1klАй бұрын
Bro what is more secure JWT or cookies session
@denicemanueli6171Ай бұрын
In real scenario where to get that public key
@YOGESH101MАй бұрын
its found on cokies or localstorage on client (browser)
@kraaakiloАй бұрын
Anywhere for sure 😹😹😹😹
@AdarshGS-j6lАй бұрын
Dont we store tokens in HTTP only cookies whose value cannot be modified at all ?
@ydkme-rebornАй бұрын
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.
@deepakmaharana12512 күн бұрын
Vruh its 2024 and you are still using background music in video
@RisalHidayat10 күн бұрын
thanks brother
@brunocarvalheiro3882Ай бұрын
this makes no sense.. it does the same action in both if parts ...
@rumaiontomal277Ай бұрын
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.
@codingboy8665Ай бұрын
wow bro thank you
@SteveBClarkАй бұрын
Awesome buddy 🔥🔥🔥🔥〽️
@arrezbrayanАй бұрын
Ahh yes "JWD" tokens
@arshansheikh732418 күн бұрын
music ❌ content ✔ Pls don't play bg music
@HarvirOfficial17 күн бұрын
Why hell anyone use public key to sign the token😂
@A3A3adamsan21 күн бұрын
What is "algordem"? :D
@itsmalayАй бұрын
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.
@coco5843Ай бұрын
Nope you can decode jwt without private key
@ydkme-rebornАй бұрын
That's not how JWT tokens work. Data you put is just base64 encoded. You can decode it and get the data.
@destroyer-medic5073Ай бұрын
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
@charmander2kАй бұрын
So confident yet so wrong...
@stefano_schmidtАй бұрын
Somebody skipped the Encoding/Decoding classes
@paulbolhar921Ай бұрын
Do you met with scam job recruters?
@Memento2747Ай бұрын
Ffs learn to say algorithm!
@He4vyD21 күн бұрын
You mean algordem?
@crooked816818 күн бұрын
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.
@artistry791918 күн бұрын
@@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
@thatguyidk123Ай бұрын
I went to Ku rock chalk brother
@tiosatria9919Ай бұрын
in almost all real-scenario in production app. this is useless.
@InMemoryOfNeoАй бұрын
which stupid is using publickey for validating the jwt? Probably 13 years old developers do that.
@xiannellegamad7727Ай бұрын
I need help
@rajsaroj6052Ай бұрын
Every realm has rbac kid 🤣
@Scotedflotsin24 күн бұрын
Bhai mai kam harami nahi hu mai phele token ko apne kud ke algorithm se pas karaya hai jise decode karna impossible hai.
@sanchitwadehra25 күн бұрын
Bhai please dont lower your standards with this kind of clickbait
@SkyDigitalElectronicsАй бұрын
❤❤
@Numi2003Ай бұрын
Algordim
@RandomytchannelGD22 күн бұрын
E
@weebernom6969Ай бұрын
FIRST :)
@ArmandoSmirnovАй бұрын
olgoridm😅
@abhisheksinha1999Ай бұрын
@sanchitwadehra25 күн бұрын
Bhai please dont lower your standards with this kind of clickbait