Hashing sensitive data in request

Question

We have set the https connection, between the client and server. The problem is that security guys, showed us it is possible to intercept the data using rogue invalid certificate (user must accept it in the browser).

The problem is now the attacker would be able to see in a clear text all the request sends to the server and though to see what is the structure of the data we are sending (is it security vulnerability?

1) Does it make sense to hash sensitive information (on the client side) and send it hashed to the server?

2) There is an requirement that require us to encrypt us some data (i.e credit card PIN) on the client side and just then send it to the server. Does it make sense? We'd have to somehow follow the same steps as we do for SSL, establish trust encrypt etc, just for this one field.

3) Is it worth to obfuscate JS code? Wouldnt it be easily reverseable?

Answer 1

The official term for an attacker eavesdropping on your connection using a different certificate is called Man-In-The-Middle attack in this scenario. The way to protect from this is pinning. An overly simplistic explanation is to check a certificate against a hardcoded copy of the original one. For more details, see the above link. My suggestion is to go with this approach as long as you control the corresponding servers.

However, to specifically answer your questions:

1) Keep in mind that hashing is meant to be one-way, so depending on what you want to do with the data it might become useless after hashing.

2) you can add another layer of security by encrypting the data end-to-end. I suggest public key crypto since you dont need to ship a shared key but just a public key with the client.

3) Completely unrelated question, but fine. JS can be increadibly mean if you have a look at code almost completely constructed from brackets and +, so you can somehow defend against reverse engineering. BUT there is no perfect obfuscation, this is an arms race

Answer 2

It is a good thing that "security guys" show you some possible attacks, it is a less good one they left you on your own pondering about counter measures.

You need to assess where your data is at risk. You have it on your client machine, on the way to the server and finally on the server itself (during processing and at rest).

TLS will protect you only during the transfer of the data from your client to the server, provided that your users are careful about certificate warnings (as shown you by the security guys) or if you use certificate pinning (as suggested by @user3363866).

Yo are left with the client and server part.

If you have requirements on protecting the data on the client you should go for well maintained systems (particularly patching) and full disk encryption. Since you mention credit card PINs in a customer context I urge you to deep dive into PCI-DSS requirements because you probably do not meet them.

When you hash "something", you get data which cannot by reverse engineering bring you back the "something". This also means that if you want to hide data in the form of, say, a US Social Security Number, it will be very easy to go from the hash to the SSN - by trying all the 10^9 hashes (you will not even need to compute them, someone has already done that for you).

Finally on the server you will make sure that the application which handles your data is correctly written and that the data which is stored is encrypted (or not, it depends on your risk assessment).

In short - it would be a good idea to get back to the "security guys" and discuss all this.

As for obfuscating JS, it does not make much sense, if the browser can understand it a hacker will as well.