Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am looking at encrypting user data however performed on the server as opposed as on the client. What risks do I have to consider and if so how do I limit such risks? The reason we are looking at server side encryption is to limit exposure on the client side to trojans, key loggers, etc


The data would be sent over SSL and then encrypted on the server. This would limit or alleviate any sniffing.

The term data is also used to describe files, etc

share|improve this question

migrated from May 3 '12 at 14:18

This question came from our site for professional and enthusiast programmers.

Please add more context. Security modeling strongly depends on whom you trust and who not. Does the client send the data unencrypted to the server? Why bother then encrypting it after it could already been read in plain text by sniffing the network? Or do you not trust the admins of the server so they do not tamper with server data? ... – Alois Kraus May 2 '12 at 9:47
@Alois Kraus - I apologize. I have amended my post with further information. The intention is not to trust anyone but the user. – PeanutsMonkey May 2 '12 at 9:49
You cannot trust the user since he might already have been compromised. A keylogger at the user input side will nullify and security mitiations you ever could set up at the server. – Alois Kraus May 2 '12 at 9:58
If you're sending it over SSL, then the client is already encrypting it. – skaffman May 2 '12 at 10:02
@Alois Kraus - But if the private keys are not held by the user but the server rather which are also encrypted, how does a keylogger nullify any implementations on the server? – PeanutsMonkey May 2 '12 at 10:04
up vote 1 down vote accepted

You say you want to use server-side encryption to limit exposure to client-side malware. That makes no sense. If there is malware or spyware on the client, then you are hosed either way. Encrypting on the server doesn't help, since the data still exists in cleartext on the client, and so the client-side malware/spyware can capture the cleartext data.

I think you need to revisit your requirements and your approach. If you are worried about client-side malware, I can see only two options: (1) ensure that sensitive data never reaches the client in cleartext, or (2) implement defenses to reduce the likelihood of malware on the client side. Encrypting on the server side doesn't really help.

Sending the data from the client to the server and then encrypting on the server has all the security risks of client-side encryption, plus some additional risks:

  • If the server is compromised, or if any of the accounts of your employees are compromised, then the attacker gets access to the data. (Twitter got hosed by the latter. Many companies have gotten hosed by the former.)

  • Because you technically have the ability to decrypt the data, it now means you can be subject to subpoenas, warrants, or demands from law enforcement to decrypt the data if they want/need access. If you are a small operation, this might not be a big deal, but at a big operation, this might start to create some compliance costs for you.

  • If the attacker can mount a man-in-the-middle attack (e.g., attacking a user who is connecting over open wifi), and if the user clients through SSL cert warnings, then the attacker can gain access to the sensitive data.

One advantage of server-side encryption is that it enables you to do key management on the server side, reducing the burden on users. For instance, if users lose or forget their keys, you can recover it for them.

Another possible advantage of server-side encryption is that the time window when the data exists on the client side in cleartext might be reduced, which might reduce the exposure to data breaches if, e.g., the client machine is stolen or lost. However this advantage may be fairly modest in practice, and there may be better solutions to this issue (e.g., full-disk encryption).

share|improve this answer
If we were developing a PC based application that would facilitate the transfer, etc, is there a way I could limit access to what malware, trojans, etc can access especially if the application resides in its own sandbox and does not permit calls to it. Or is that view too simplistic? – PeanutsMonkey May 21 '12 at 18:51
@PeanutsMonkey, no, that does not help, and my answer does not change. It doesn't help to put your legitimate software in a sandbox, since the malware won't be constrained by that software. A sandbox would only help if you could ensure that the malware is restricted to execute within the sandbox: but in practice, you can't, so it doesn't help. So, my answer remains applicable to that setting as well. – D.W. May 22 '12 at 5:41

I'll start with a simple authentication system.

You ask the user for his login/password, that you send to your server. In the server, you hash the password to compare it to the database (I won't talk here about the importance of hashing a password and using salt & pepper).

No, using a non encrypted (SSL) connection, someone between your user and your server can read the transmitted data (known as Man In The Middle attack) and know your user password.

For that, you can use a SSL connection to protect your user from being read while sending data to the server. It's the best secured way so far (again, I won't talk about the limitation of SSL here).

But an other alternative can be made. You can hash the password using md5/sha directly in your user's browser and send you the hash. Some Javascript libraries exist for that. But you need to remember that not all your users will have javascript enabled (except you force them to use it). Moreover, using this method, you won't be able to add a salt and pepper without compromising the overall security.

Moreover, don't forget that this won't protect you agains't keylogger, trojan and others. Just MitM attacks.

Now, for the file upload. The default file upload of the browsers, I mean <input type="file" /> won't send data encrypted. If you want to do so, you'll have to implement a Java or Flash system for uploading file that will encrypt the data before sending them to the network. Again, this won't protect your users if they have a virus on their computer.

Remember that the ideology between client <-> server is their relation between them. You can't protect your user from having viruses, you can only improve the security in the link between client <-> server and also your server.

Now, if you want to protect your server for malicious code upload, enabling security in the client side will be useless. You can't never trust what users sends you. Even if you build the most sophisticated html application, someone will be able to send you data without using this app.

All you have to do is improve security in your server side : checking if the file sent is the correct type by checking it's mimetype (with the right tool, not only the extension!). Always refuse files that can be executed (.exe, .sh, etc) and more over, be sure on what to do with those files. (You can allow upload of .php files, but you must put them on a directory where they can't be executed from a remote location!)

share|improve this answer
If you hash a password on the client side and validate it against that, what's to stop the man in the middle from just capturing the hash and then sending it to you again at a later time? Would a time-sensitive hash be used or are there other measures? – Jake Woods May 10 '12 at 14:41
Hashing the password wouldn't ensure that the mitm would gain access to the app, but would avoid him to know the original password. But again, without the salt & pepper, it just add a little layer of complexity, but it's not impossible to get the password back. – Cyril N. May 10 '12 at 14:43
Who cares what the original password is? I'm just going to POST the MD5/SHA I scrapped of the network traffic to the server and log in as you. The only thing you prevent me from doing is using it against other sites, but I'm still fully able to violate the account on the server that uses this rather useless method of security. – StrangeWill May 10 '12 at 16:52
The original password was a precision about the potential lost and reuse on other site. To prevent the attacker to log in as me, use SSL as I said. – Cyril N. May 11 '12 at 6:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.