With Network Security Systems Decrypting SSL traffic to scan for Malware Is Server-Side hashing of Credentials Still Enough?

Question

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?

Answer 1

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:

• Basic Auth RFC1945 s11.1 Basic Auth - Page 48
• Form-based Auth
• Digest Auth
• Open Auth
• Why not to roll your own crypto

Answer 2

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.