I'm looking for a pattern to store a config file containing sensitive information in a semi trusted hosting environment. Semi trusted in this case meaning I trust them in general, but not with this info (passwords).

In this case I'm writing a simple daemon to watch a folder for changes, and push those changes to a database hosted somewhere else. I'd rather not store the details for that database in plaintext in this semi trusted environment, as I'm unsure if the admins themselves would use it maliciously.

My original plan was to setup the necessary reporting scripts in my untrusted environment, and then execute them remotely from a trusted location, sending config vars on each execution. However it would seem that they log all commands executed on their servers, so this is a no go as they could simply review those logs.

Alternatively I could have a second layer database, whose credentials I store on their server. This database would act as an in between, allowing one set of scripts in an untrusted environment to push data to it, and another set of scripts in a trust environment to pull data from it and move it to it's final destination. I'm less concern about them maliciously corrupting the data, and if they access this database it isn't a big deal as it's entirely separate from my main data store.

This method is rather cumbersome and not exactly secure, so I'd rather avoid it if I can.

Moving away from this untrusted environment is not an option, unfortunately.

  • Possible duplicate of Storing sensitive information securely. Either case, you might want to read D.W.'s answer to that question. Another approach is building something similar to DRM schemes (they were meant to protect contents in an untrusted environment also), but I don't see it possible without some sort of dedicated hardware like HSM, or at least a hardware key that would pair its signature with hardware it attaches to.
    – TildalWave
    May 22, 2013 at 4:03

3 Answers 3


If you're worried about the admins actively snooping on your application, there's nothing you can do except never use their system with any sensitive data. Whatever your program does to decrypt or retrieve credentials, they can also do. For the same reason, you need to trust them not to allow administrative access to their system to any untrustworthy third party.

One area where there is some room to mitigate risks is reaction time in case of a breach. It is difficult to give general advice there because this is a compromise between availability and confidentiality — if something “weird” happens, do you want to take the system down as quickly as possible (and page you to come and sort the whole mess before service can be restored), or do you want to keep running as long as possible and notify you that something may be amiss? Note that even with best effort, you can never be sure that a breach won't happen undetected.

You can slightly reduce the risk by storing the credentials remotely and retrieving them on each connection or at short intervals. For better results, use a password that changes automatically every few minutes. That way, if the server is compromised but the attacker wasn't initially after your application, you may have a little reaction time when you can decide whether to shut down service — just turn off the credentials access. This isn't foolproof; if the attacker is after your application, he'll start using the credentials before you can react. In any case, make sure you can change the credentials quickly before breaking anything else (so no shared password that needs to be changed in 20 different places).

Another way to mitigate risk is to give this semi-trusted system as few privileges as possible. In your situation, the semi-trusted system only needs to push changes into a database somewhere else, so don't give the semi-trusted system any credential that lets it access the database directly. Only give it permission to append records to one table, or some such. Use a proxy application (running in a fully trusted environment) rather than direct database access to perform this authorization check, and make it log everything it does. That way, if the semi-trusted system is compromised, you may end up with fake records (together with a timestamp and perhaps other information that may let you sort the good records from the fake ones) but anything that isn't derived from these records will still be safe.


Don't waste your time on this. There's nothing you can do. You're placing your data on a server that is not yours, and people managing this server can have access to your data.

Let's say you found the best way to store database credentials securely. Your server admin has a DBA account that can access your database anyway. Nothing you do will solve this, not even a VPS (Virtual Private Server). So here are you options:

  • Get a high-speed connection and server-grade hardware, and build your own server at home, office, or any trusted location.

  • Register with a well-vetted and reliable web host.


If the site can access it, the admins can access it. If they wanted they could simply alter your web site to display the configuration information. There is no way you can protect it if the site needs to access it. The only alternative is to move to a trusted environment. Virtual Private Servers are pretty cheap these days.

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.