views:

476

answers:

4

Hi,

I have a windows service that reads from app.config.

I want some settings to be encrypted, however, I don't want to use the ProtectedConfigurationProvider classes provided in .NET because they encrypt files based on the machine they are running on using DPAPI.

What I wanted was a way for our administrator to deploy the config file already encrypted to many machines and have each machine decrypt them when needed.

I don't want to hardcode a password into the assembly either so I'm not sure how I can go about this.

+7  A: 

reduce the problem to its simplest form:

  • you have a program
  • that will be given an encrypted file
  • and you want to decrypt the file
  • without hard-coding the key

the obvious solution is to ask for the key when needed from a trusted third party

Steven A. Lowe
this is not acceptable, the user should not have access to this password nor should someone be standing there entering the password when required.
Sir Psycho
a trusted third part isn't necessarily a user. Possibly an authentication server of sorts
SnOrfus
@[Sir Psycho]: who said anything about a user? the typical trusted third party would be a keystore, secure web service, et al
Steven A. Lowe
+1  A: 

One possible way to do this would be to include the decryption key at the beginning of the file, and the key has been reprocessed in some fashion that you can determine from the key. One possibility would be to pick, like, say sixteen different things, 0 being, say, rotate the first two bytes to the end; 1 being rotate the last two bytes to the front; 2 being add 1 to every byte; and so on for 14 additional functions. Now add this value in front of the key as the "reprocess flag".

The first byte of the key would then be a branch table to one of 16 different routines to say what to do with the key. Note that the reprocess flag doesn't have to be the first byte, it can be any byte in the key as long as you remember to throw that byte away when handling the key.

Then you process the key according to whatever decryption algorithm you would use.

Now, given this reprocess flag - especially if the entire key was in hexadecimal - would require someone follow the logic to determine which of the 16 different functions your code executed, then figure out the decryption method. It's not going to stop everyone but it will probably do a fairly good job driving away all but the most determined.

this is still technically hard-coding the key, just obfuscated in the config-file instead of extant in the code - +1 for the thoughtful answer though!
Steven A. Lowe
A: 

Hi everyone,

I thought I'd post my answer on this as I've found a solution.

What I plan on doing is this

  • User starts application
  • Application sends public key to server
  • Server encrypts password with public key
  • Encrypted value sent back to client
  • Client application decrypts the password with private key and uses that password to decrypt the config file when needed.
Sir Psycho
this is the trusted-third-party solution!
Steven A. Lowe
You have a hard coded private key in the application and a server willing to send the encrypted password to that server... is that really more secure than having the password hardcoded in the application in the first place?
Patrick
A: 

This appears to be a duplicate

Sam Saffron