I am not a Security Expert by any means. Nor am I a Cryptographer. That's why I'm here.

After discovering that the server side of some software I work on was operating on plain text passwords (though I later determined that only the hash was stored in the database) I started researching into what parts along the way between the client and the server the password was in plain text.

To my surprise (I'm ignorant remember?) I discovered that I was able to view the password in plain text at every step in the process, client side debugging of javascript, packet inspection of network packets, and debugging the server log in code.

I, of course, had a heart attack. I couldn't believe that the software I was working on would ever allow someone to read a password in plain text at any point after the login button was clicked. So I started researching the question.

First I determined that the network packets were indeed encrypted via SSL. I had implemented a MitM attack against myself using Fiddler to decrypt the packets. This eased my worries, but only for about 60 seconds. I then discovered a number of blog posts by security companies advising their readers to DECRYPT and INSPECT the SSL packets being sent across their networks. The reasoning being that even Malware can use SSL, and that it often does exactly that to hide from firewalls.

Here's where I started to get concerned. You see, I don't trust anything or anyone when it comes to security.

If a security administrator can decrypt my SSL packets on my corporate network, why can't a bad actor working at my ISP do the same thing?

I started researching how passwords should be transmitted via HTTPS, and ran into an interesting debate, that is mostly settled, from the early days of HTTPS. This was the debate on Client-Side vs Server-Side hashing. Server-Side hashing makes perfect sense, and clearly wins in a situation where the network packet encryption is practically impenetrable, but once you have a company's IT department decrypting those packets, is server-side hashing really the only thing we need?

  • storing the hash is for protecting the password in case the server's database is stolen. Using a hash on client-side ("remember me" type cookie) is for protecting the password in case the client's cookies are stolen. MITM mitigations are more complicated. Aug 23, 2021 at 21:43
  • my purpose here isn't to ask if we should abandon password hashing on the server side. My purpose is to ask whether it would be better to ADD client-side password obfuscation of some sort, whether it's hashing, encryption, or some other method I'm unaware of.
    – Catachan
    Aug 24, 2021 at 13:26
  • though it'll do nothing to help with MITM, if you are storing passwords client side you can encrypt them using the machine's serial number or something similar as the key... something unique that has to be retrieved from the machine each time it's decrypted. That offers a tiny bit more protection in case the encrypted password file is stolen, but they do not know the method of encryption and/or are not able to run an executable to poll the machine for the info. (not possible if the client is a browser) Aug 24, 2021 at 16:15

2 Answers 2


Ok, lets take these items one at a time.

I discovered that I was able to view the password in plain text at every step in the process

This is actually normal. If you hash-ed the password client side then the hash would technically become the new password. Attempting to encrypt the password client side is arguably worse because clientside javascript should never be "trusted"

So, industry standard is to enforce HTTPS and then send the password in cleartext to the server. The server then hashes it and compares the hash to the hash stored in the database.

only the hash was stored in the database

This is par for the course. Salted hash would be better, but a hash is MUCH better than storing the password cleartext.

If a security administrator can decrypt my SSL packets on my corporate network, why can't a bad actor working at my ISP do the same thing?

The difference between a security admin and your ISP is that the security admin has administrative rights on your computer and can thus install a HTTPS cert that will allow for the MitM Proxy to work with out prompting a big scary error. A rogue actor at the ISP does not have access to your physical machine and thus if they attempted to MitM your connection you would get a big nasty error saying the cert didn't check out.

Further reading:

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – schroeder
    Aug 24, 2021 at 19:30

If a security administrator can decrypt my SSL packets on my corporate network, why can't a bad actor working at my ISP do the same thing?

In order for an IT department can decrypt your HTTPS traffic they need to install a trusted certificate on your device - which they can do because they control all of the endpoint devices. A random person at your ISP can't do this. And if an attacker can install arbitrary stuff on your device, they could just install a keylogger or any other malware they wanted.

Now it's true that they might be able to get hold of a trusted root certificate by compromising a publicly trusted certificate authority. This would be difficult for a random attacker, but is well within the capabilities of a nation-state level actor (or they could just force a local CA to give over their certs). But as soon as they got caught the certificate would be revoked, so it would be an expensive attack. And realistically, as an individual, you probably can't defend yourself against a nation state anyway.

The problem with client-side hashing is that it doesn't really achieve much. If you starting point is an attacker who can decrypt all your TLS traffic, you've already lost. Sure, you can hash the password client-side, and if it's a good password they might not be able to crack it. But why would they bother?

They can just read your session cookies/tokens, and the full contents of every request or response you make. They can probably also inject a JavaScript keylogger or browser exploit into the page, or serve you malware in what you thought was a trusted file.

  • Most attackers aren't active attackers. You're far more likely to encounter someone perusing the server logs, noticing the username/password combo of "Gh0stFish/hunter2", and trying it on a few large banking sites.
    – Mark
    Aug 24, 2021 at 3:31
  • @Mark, Perusing server logs is actually what I've become more concerned about after doing a bit more research into this. Apparently logging PUSH requests containing plaintext passwords has happened a number of times since HTTPS became the standard. The biggest instance where they were logged and then compromised was probably with FaceBook a few years ago. I'm a Software Engineer, and I don't even trust myself not to make mistakes like that.
    – Catachan
    Aug 24, 2021 at 13:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .