Should I encrypt sensitive form data with JavaScript on the client?

Question

This is by no means a replacement for HTTPS, so please do not assume that is why I am asking this question. I am exploring, and I am curious. I am looking for some expert input on this, and I am not entirely sure where I should ask this.

Okay, so say I'm sending really sensitive information (bank information for example). And I want to take a step further to protect it.

With JavaScript, I would encrypt the form data when it was submitted. Then I would decrypt it on the server (back-end).

• The first option would be to use asymmetric encryption alone. Encrypt the form data on submission, with the public key. And since it is public, it cannot hurt for the client to know it. Then on the server, decrypt the data with the private key. Which is obviously private, and only the server knows it.

• A lot of asymmetric algorithms are really slow from what I have heard, and can be quite limited in terms of how much you can encrypt(RSA for example). So what about hybrid encryption? Encrypt the form data with symmetric encryption (random key generated every time), then encrypt the symmetric key with with the public asymmetric key. Send the symmetric key along with the data. Decrypt the key with the private key, use the key to decrypt the data.

What do you think? I am a little lost as to which would be better. And how to go about this.

Answer 1

Best case scenario here is that you are wasting your time. Generally, doing client side encryption on top of HTTPS in a web application is a lot of work, but it provides no extra security.

The purpose of an extra crypto layer would be to protect against a MITM that has somehow managed to crack the TLS encryption. But an attacker that has done that could easily just modify the JS source of your extra crypto, simply turning it off. So this would only be useful against a passive MITM that has cracked TLS, and that really isn't a threat model worth investing a lot of energy protecting against.

Also note that limitations in many browsers (Opera Mini, IE9) ability to generate secure random numbers makes client side encryption tricky. You should never rely on Math.random for anything crypto related.

You should focus your energy where it has maximum impact. Instead of implementing your own crypto, make sure that you are using the good crypto you get for free with HTTPS correctly. If you are worried about MITM-attacks, looking into HSTS and preloading would be time much better spent.

Answer 2

Probably Not, but...

Most of the information described in @Anders response was correct, and should be recognized as the correct response.

If we are assuming that you are performing the encryption specifically for the client-server session taking place, there will be no added benefit over just using HTTPS.

However, since you explained that you're not looking for an alternative to HTTPS, I'm going to assume you are exploring one of the following scenarios:

1. You're creating a multi-tiered server architecture, where you only want servers with elevated permissions to be able to read the sensitive data.

2. You want to be able to store the data at rest in some database, but only want some of your servers to be able to read it.

3. You actually just want client-side encryption, where the server can't read it, but can store it.

---

Caveat Emptor

All three of these scenarios rely on the assumption that you can trust the server code to some extent. (This could work in structured organizations that have heavy code review).

---

Traditional Methods

Option 1 could be implemented traditionally by enabling CORS and allowing the client to communicate with your "elevated" server. However, this requires you to open your "elevated" server to the internet.

This typically involves tokenization, and is an approach used by many payment processors.

Option 2 could be implemented server-side, by encrypting symmetrically prior to inserting the data into the database.

---

Non-Traditional Methods (for the sake of education)

Let's say you have a unique mix of options 1 & 2, or you want to explore option 1 without opening the server to the open web.

Yes, you could use a hybrid crypto-system (asymmetric + symmetric) to effectively encrypt data that only specific servers could decrypt. Implementing such a cryptosystem is a challenge, and requires expansive cryptographic knowledge to do correctly.

For option 3, you could encrypt/decrypt symmetrically client-side to protect the user data. This would likely require a variable to be stored in localStorage (for convenience), which carries risks (it's easier to hide code that scrapes it).

These approaches could assist in making it more difficult for employees in a structured organization to steal user data. But it only works if the data encryption mechanism can't be tampered with, or the credentials can't be stolen.

Encryption won't be a silver bullet in any scenario I can imagine. It can mitigate quite a few attack vectors, but it won't resolve all of them. You'd need intense code review.

Answer 3

The system you describe is end-to-end encryption (E2EE), which when deployed correctly can ensure not even the server can access the contents. However, for your usage, the only systems to be able to decrypt the "sensitive information (SI)" will be the client and the server.

Upon submitting the SI you will download the server's RSA public key, likely RSA-2048 will suffice here, as you can generate new key-pairs manually on a frequent basis. RSA with JavaScript could be a good starting point, as it shows how you could encrypt a string with the public key and offers decryption options as well within the source code. Storing the RSA private key secure may prove challenging. You could handle this by using PHP or Python (via a CGI gateway). Then ensure only the compiler has permissions to access private key, this will mitigate risk. As if the web server has access permissions and is ever compromised it could access the private key.

Next, a symmetric encryption key (SEK) is required. I was looking at Generate random string/characters in JavaScript, which while not perfect for this scenario, should give a good building block for what is required.

Having not used an AES JavaScript implementation before I will provide Javascript AES encryption. I felt, 'JSAES is a powerful implementation of AES in JavaScript' seemed like a simple option. However, this will need to be your decision.

Now when you submit the ciphertext (plaintext encrypted AES) to the server, you should ensure the client knows decryption was possible and allow for validation. AES_Encrypt(plaintext, key) so AES_Encrypt("Validated", "$key"). This ensures the server was able to encrypt a message with the (encrypted symmetric key) and the client was able to decrypt the expected message. I should mention AES 128-bit or 256-bit will suffice equally. Obviously, AES 256-bit is better, but given the RSA-2048 is the weakness in the chain, AES 128-bit with RSA-2048 might be more ideal, as overhead will be reduced.

You are now validated. Ensure that the symmetric encryption key is only valid for X minutes, say 60 minutes. Before a new session key is required. This will prevent key-reuse abuse.

To summarise:

• Fetch RSA public key
• Generate random 32 character string (symmetric key)
• Encrypt (symmetric key) with the RSA public key
  • Producing ciphertext
• Submit the ciphertext to the server for decryption and validation
• Decrypt the ciphertext with the private key
• Encrypt the expected (known) message using AES and the symmetric key
  • AES_Encrypt("Validated", "$key")
• Client decrypts and validates secure authentication is complete.