I have a Windows service which connects to a database to poll some value in order to monitor certain activity.

Of course, to use this I need a database password. I need to keep this password safe, since it is of course not supposed to be common knowledge. In order to do this, I have developed a simple XOR cipher and stored the ciphertext in the config file. The key I have used for the cipher has for now been hardcoded into the service.

Of course, this hard coding is not ideal, since somebody can disassemble the .exe and see both the key and the cipher!

I am not expecting most people to be capable of doing this, but I feel it is best to mitigate risk where possible. So, is there perhaps a better approach to this problem?

I know it is always best to use an existing solution where possible, but I couldn't find anything specifically that would work in this case. I looked at the Windows Data Protection API, but from what I could tell that only worked within one instance of an application. It would not allow me to store the ciphertext in a file and access it later.

  • Can you break the process into setup and runtime such that during installation, you can read the password from file and then use Windows Data Protection API to store it "securely". After that you application can read the information using Data Protection API and perform relevant operation. – jhash Sep 29 '15 at 12:26

If the password is going to be used and stored somehow on an untrusted client, then there is no real way to secure it. It would be in memory at point of use, and could also possibly be sniffed by a MITM impersonating the server.

A better solution would be to have a remote Web API with read access to the database table containing the value that needs to be monitored.

The Windows service then queries the Web API. If the data is sensitive, it is prudent to secure this service with some type of authentication and to protect it in transit using TLS. However, the main point is that if a client discovers the API credentials, the worst they could do would be to query the value being returned which is what the Windows service does anyway. That is, they won't have the access to read other tables, or to write to the database server. The API will only expose the one function, and the API itself would only have the minimal permissions necessary.

  • 2
    Wouldn't it be simpler to just create a generic user id password with limited access in database to do what you are proposing? Most of modern databases support SSL/TLS for transport layer security and have mature access control implementation. Adding an abstraction layer with custom authentication & authorization model may be greater risk than letting database handle the same, where possible. – jhash Sep 29 '15 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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