Client side encryption - only web browser available

Question

I am creating an enterprise application, the server side runs a whole set of different apps, On the client side, there is only a webpage, no applet or anything else. Unfortunately data created by the user can be confidential, so I need to encrypt it somehow.

From what I understood, JavaScript cryptography is not a good idea. What about generating the key on a third party server and send them to the client? It feels like just moving the problem somewhere else, not fixing it.

Could you give me some advices? I don't really see how to encrypt the data.

Answer 1

SSL/TLS is the encryption layer between browser and server. As long as you have properly configured your SSL/TLS on the server, any additional javascript type encryption is redundant.

If you are trying to create a secure application, and your team does not understand what SSL/TLS does, you might want to consider bringing in a security consultant to help you with these architectural details, and make sure you avoid any pitfalls.

Answer 2

JavaScript cryptography is not a good idea

JavaScript cryptography is not bad per se, it's just ineffective against most commonly considered threats.

If you consider a man-in-the-middle (MITM) to be a threat then SSL/TLS is a much more effective control as otherwise the attacker could substitute the JavaScript for a version which doesn't use encryption.

If you consider malicious software on the client side to be a threat then it could presumably modify the JavaScript any way it likes and your encryption would be useless.

If you consider the server side to be a threat (eg. the client wants the server to store something but not see the content) then it may be effective, but the client needs some other way of ensuring the JavaScript hasn't been tampered with (which isn't an easy problem to solve) and the client needs to manage the key themselves.

In the use case you've described it doesn't sound like client side encryption will really add any additional security. Either way you have to deal with the issue of communicating the key, which will probably depend on the integrity of SSL/TLS regardless. Either the client will have to send the key to the server or the other way around, and even if you use public key encryption to address this you'll still have the issue of ensuring that the public key sent to the client is authentic. You'll most likely just end up reimplementing a typical public-key infrastructure.

All that aside, there's no fundamental issue with performing cryptography in JavaScript, except that:

• It is typically fairly slow by most standards
• Generating cryptographically secure keys can be an issue, particularly in older browsers which don't support certain newer APIs for this task

Answer 3

Have you think to use SSL/TLS on server side. So the data will traverse over secured channel. And on server side later you can encrypt ti and store it in such form in the database

Answer 4

From the OP's comments it doesn't sound like this would be useful to them, however, it may be useful to others.

It's possible to usefully encrypt information client side, but the use cases are few and far between.

Example use case:

1. The user needs to work on confidential (as least by their judgment) documents which must be stored locally (perhaps to lower server costs)
2. The computer they work on is not secured (enough) from other users (ie someone else can open their browser)
3. However, it is secured enough that the other users could not tamper with the OS, the web browser, or hardware. (sounds far fetched but maybe something like a shared kiosk machine that's been physically secured)
4. The user is willing to enter a password whenever they start their work.

In this case the javascript application could be delivered over TLS. The documents could be encrypted with whatever two way encryption is deemed acceptable. The key could be derived from the users password, and would only be stored in memory. If any of the above was not true javascript encryption would be superfluous as follows:

1. If the documents can be stored on the server, then TLS could cover the issue and the sever can deal with encrypted storage if necessary.
2. If only owner has access to the computer then the documents could just be stored in local storage.
3. If the computer is public, then a key logger, or malicious version of the browser could be installed and there's no security that's viable in that case.
4. If the user could access their work without an additional password then any user could access their work.