0

I have read extensively on SO and on the .NET but still do not think I have a workable solution or I have not considered something.

I am looking at an application that as part of its functionality has to write a document to disk on the web server.

Now assuming the worst and the web server is penetrated and the attacker gets to the file system or due to a misconfiguration of the web server the file is available via HTTP. It seems that encrypting the file would be sensible.

  • However would you suggest I use symmetric or asymmetric encryption?
  • At some level there will be a secret password that is accessed by the C# code. How do you obfusticate that? Or put another way how to you deal with using secret keys in code in a secure fashion?

All help and pointers greatly appreciated.

TheEdge
  • 9,291
  • 15
  • 67
  • 135
  • You could use [Password Hashing](http://stackoverflow.com/questions/326699/difference-between-hashing-a-password-and-encrypting-it) – Kurubaran Nov 10 '14 at 09:55
  • think of compilation is a kind of encryption. you use a key stored in the source code and it's compiled and only required .dll's and .exe's are stored in your system. you know that the executables aren't human-readable. that's why ide's are warning you if you place a username-password in your config files. – İsmet Alkan Nov 10 '14 at 10:04
  • @Kurubaran Whether the password is hashed or encrypted still means that is what is going to be used as the key. So if an attacker gets hold of a disassembly of the code they still have the password. So not sure how that would help? – TheEdge Nov 10 '14 at 11:15
  • @IsThatSo As this is .NET a simple disassembly of the assembly in question and everything is laid bare. So no help there. – TheEdge Nov 10 '14 at 11:16
  • makes sense. so you'll have to use asymmetric encryption. i suggest reading public/private keys. – İsmet Alkan Nov 10 '14 at 11:26

1 Answers1

0

You mention that your app has to write the document, but does it have to read it? If not, then you can create a file service where you can only write to, but not read from, and problem solved. Also, if you use asymmetric encryption, the app can encode the document with the public key, but it won't be able to decode it without the private key. If the private key is not there, then again, problem solved. Otherwise, if the app has to be able to read it, the only thing you can hope for is security through obscurity, obfuscating the encryption stuff. But if your server is compromised, they can save both the document and the code that created it, and you can't stop them from eventually revealing the contents, no matter how hard you try. So it depends: how hard do you think the attackers will try? How hard do you want to try? What are the costs and benefits of investing into more security?

fejesjoco
  • 11,763
  • 3
  • 35
  • 65
  • Yes the application has to read the document again unfortunately. So for instance a user is generating the document which is stored on disk for audit trail purposes, but the user may visit the site and want to look at the document once more. – TheEdge Nov 10 '14 at 11:18
  • If I were the attacker, and the document was encrypted, I would just hack the application so that I could impersonate the user. Then the application would happily decode the document for me. I see no point in trying to handle this case. Just make sure your server doesn't get hacked in the first case. – fejesjoco Nov 10 '14 at 12:01