No, You Don’t have to Encrypt Passwords before sending POST requests and here is why

I discuss why you don’t really need to encrypt the password before sending your POST request to the wire, TLS is enough. If you do not use TLS then it is very dangerous to do so.

🏭 Software Architecture Videos

💾 Database Engineering Videos

🛰 Network Engineering Videos

🏰 Load Balancing and Proxies Videos

🐘 Postgres Videos

🚢Docker

🧮 Programming Pattern Videos

🛡 Web Security Videos

🦠 HTTP Videos

🐍 Python Videos

🔆 Javascript Videos

Support me on PayPal

Become a Patreon

Stay Awesome,
Hussein

[hnasr]

After a year of making this video, I would like to add some additional information so you can make a better decisions. I still stand with what I said in the video. In most cases developers don’t have to perform additional encryptions of their POSTed passwords on top of TLS. However, Now that I know little more than I knew a year ago, TLS can be terminated between hops, CDNs, reverse proxies etc. This leaves those hops reading traffic in plaintext. if you own those hops than this is not a problem but if you don’t trust these hops (Microservices architecture service mesh that terminates TLS) you might want an additional encryption to sensitive information like passwords. Easiest way is through PKI. That is the only case where I think you should apply additional encryption to the password.

That however comes with a price key management, if you used PKI to encrypt the password at the client side how do you know thats its actually the server’s key and not a MITM? In TLS we have certificates. You will slowly end up implementing the entire TLS again. That is why its not as easy as it sounds. Relaying on TLS and TLS Passthrough whereever possible is a better solution in my opinion

[letsflow.oficial]

The best explanation that I found on the web for this common mistake. Thank you for your service, Sir!

[tekfreaks]

I had this doubt before landing on your videos. Thankfully, you are making everyone's basic clear. Thanks Hussein :)

[buddhikanelum]

Thank u for the clarification. always had a doubt about the "should I encrypt the password in client-side?" thing. now it's clear.

[georgethomas]

Thank you so much. I have been arguing exactly the same point with a firm who has given me an L1 report forVAPT citing I’m sending password in plain text and have been asking me to salt it.

[shubhamtomar]

Thank you so much. All my doubts are clear now.

[ThePapanoob]

I agree with your statement about tls being secure, but i dont see that as a reason against encrypting passwords on the clientside. The almighty google has far more security measurements in place to be secure against server compromises than the average Website Operator. In the real world where you see people just installing wordpress and 350 plugins, servers get compromised alot more often wich is why one could argue that hashing on the clientside is a good thing. Thats also the reason why i always propose to seperate the backend and frontend so if the backend gets compromised the frontend still is good to go (i.e. no replacing the frontend code to remove the hashing of passwords)

[rishujain]

Thank you. Cleared up my concern very very perfectly.

[kidscodera]

please tell me what should I do to implement TLS or HTTPS ? any package or any library or what should I use ?

[odmllrq]

Thank you very much, This was very very useful, thank you again

[MohamedEldoheiri]

Just following your advice to question everything!

In some protocols like 3ds2 for payment authentication, the requests and replies are encrypted on top of TLS where before starting a payment authentication session a diffie helman key exchange is established between client and server, why bother in this case?
Also you said the client has to keep a key to encrypt the password and everybody can see it. But what if the server sends first their public key, the client generates a random symmetrical key encrypt it with the server public key and then establish this random key as the session key and encrypt the password with it.

Also https is not bullet proof, if the system is compromised and the TLS trusted certificate store on the OS system is compromised then a man in the middle attack is possible.

FYI, I am a big fan of you Hussein and love your videos, I am just arguing that in some sensitive scenario's where the stakes are higher like payments, encrypting the password might be worth it.

[pravin]

Hi, Hussain I need encrypt file using PGP. but I have some limitation I not able use already excited js library like openpgp.js I need write my own hand. Where I start? It's possible?

[trijit]

Please also add this to video bucket list: How URL shortening works?

[capecoralgreg]

But when a network admin has the cert key, they can see the plaintext password over TLS using any number of packet capture tools.

[EchoVidsu]

No wonder I didn't find much on the web about client-side encryption

[MuhammadUsman-jcoq]

if you are saying the data gets encrypted then why they are encrypting other things on their own except the password, do TLS only encrypt the password?

[naveenpixeler]

When I connect to Public wifi, isn't that password can catch in the network?

[kumarvadivel]

hussien the main reason to do client side encyption is if any attacker who compromises the logs might get the passwords easily so it is always recommended to encrypt on client side

[ashishchandra]

Hi Hussein. Please post videos on Backend Engineering, Security for IoT based systems.

[mathiasfantoni]

3:53 Don't store unencrypted passwords on the server. If the server gets hacked, you will have a password leak if the passwords are not encrypted. Always encrypt sensitive data that you don't want hackers to have.

If you're making a login system, encrypt the password using the same salt and pepper and compare the encrypted result to the encrypted password in the database. Why would you ever decrypt a password?

Also if the server knows your unencrypted password, you basically have to "trust" that they don't peek at your password before encrypting and storing it. If you encrypt it on the client side, you can verify that the admins don't peek at your password before it's encrypted, because it's already encrypted before reaching the server. Google could potentially peek at your password and run psychoanalyses on it to try to figure out something about your personality based on the password you chose. They wouldn't be able to do that if the password was encrypted in the POST request.