If the files are encrypted prior to uploading, then the advantage would be that a "man in the middle" attack that might be able to intercept the file transfer would not have the key, though if using HTTPS, I'm not sure if that's overkill or not -- depends on the sensitivity of the data and the strength of the encryption. In any case, every additional layer of security helps, if just to make the idly inquisitive hacker (as opposed to one specifically targeting you for some reason) go look for easier pickings.
I decided to implement it anyway. I figure if we get hacked or audited it will be a lot better then nothing. I also used two servers for the key. I am using an IIS site on our domain controller to store part of the key, so if a hacker were to gain 100% of the content on our web server then in theory he would only have half of the key to decrypt any files.
why don't you encrypt the key on the server as well ?!
That does not work. If the key is encrypted, then the key to decrypt the key needs to be stored on the server, so you run into the same problem. These files are accessed by many different users, so its not like I can use their key to decrypt/encrypt the file.
One crazy idea I had tho, for a future implementation, was something along the lines of this:
Each user uses their own password to encrypt/decrypt a secret hidden shared global password. Then its that global secret password thats used to decrypt/encrypt the files. Some interesting points about this method:
- the key is only ever stored in session vars which can be encrypted/decrypted only with the a key the user has in a cookie (and if you wanted, this could be half of the keyfile with the other half on another server)
- since users need to login and give their passwords to access the system, it would require no extra additional steps for them.
- when users change the password (ldap for example) they would need to provide their old password on their first login so the secret keyfile can be re-encrypted with new password.