What is a proper or, if possible to tell, the best way to store configuration in matters of security?

So far I can tell that a database with very restricted access is a good way, but please let's exclude the database for the moment. I'm talking about things like encrypted properties files. As this is already a suggestion, I would also like to know about something like common mistakes or things I definitely have to keep in mind to acquire a secure configuration. There are already related discussions on "the best way to store configuration", however I wasn't able to find something with focus on security.

The application runs non-distributed on a host-machine, so the configuration is stored on local system. The application is, so to say, a single user application. We are talking about something like a software-firewall to be concrete. I'm actually thinking of application-scoped settings. I need data protection in a sense of privacy (I don't want to expose functionality and configuration) and integrity. I'm not afraid of an insider (admin) but more of intruders.

I already asked this question on stackoverflow but I think it is more appropriate to ask it here. I will delete the stackoverflow post in timely manner.

  • 1
    Securing a configuration file from non-administrators? Just set the DACL on the file not good enough?
    – Paul
    Sep 22 '14 at 9:34
  • "Just set the DACL on the file not good enough?" - I dont know :\ is it? I am asking this question, because im not rly aware of the attack surface of application configuration files. If you can explain with some sentences why a DACL configuration is sufficient my question is answered, i guess. Sep 22 '14 at 10:09
  • What commes into my mind here is also: I would like to have "secure-by-default"-configuration as it is always recommended for sensible applications. Depending on DACL I cant get my configuration completely secure on delivery. Or do you think it may be legitimate/unproblematic to set the DACL on installation process? Sep 22 '14 at 10:19
  • You can use GPG to sign git commits. If your goal is to ensure the integrity of your configuration vs hiding it from unauthorized use, you could verify using GPG in this way.
    – earthmeLon
    Mar 20 '15 at 21:12
  • You really need to be more thorough in how you define intruders. Where do they come from, what privileges do you expect them to have, and what privileges does your app require to run? This is a classic operating systems security question, not an application security question (i.e. it's not so much about what you do as an app dev but what the sysadmin who uses your app does to restrict access to its data). Oct 14 '15 at 10:29

Ok, so if a hacker gets into your system you want prevent him to seeing the configs? By the logic, IMO this is not possible. The application needs to read the config and it needs to store the config values in the memory. The hacker with root privileges can always dump the memory and reconstruct the config (if the application is running).

However, you can make it harder for him. For instance, you can keep the config encrypted. The application would ask for the password on startup and use the password to decrypt the config. However, I can imagine, this could be quite annoying for sysadmins ;-)

  • Okay speaking about "annoying", it depends right? On a server that runs permantly (in theory) it is not too bad I think. However "making it hard", as you wrote, is maybe what I am asking for as security is always relative, I mean it is not even proven that asymetric cryptographic works in means of security. So thanks for the answer. Still, I am not satisfied as I would like to see an assessment of approaches to this security issue. Simple encryption and decryption on start up is fine, but is it THE answer to this problem? Maybe, i dont know. Thank you so far. Sep 22 '14 at 13:22
  • But also, "annoying" could be really annoying. ;-) Keep in mind, you can't restart the application without a human attention. If you don't really trust your applications, and coders usually don't, you should be prepared for waking at 3:00 morning :-).
    – smrt28
    Sep 22 '14 at 13:27
  • 1
    Yes of cause, it would, in fact, annoy me (in person). However as I am very fussy in this issue, as you might have noticed and we are speaking about securing application configuration, while an attack on configuration is not rly in any top attack list i seem to talk about a very high security claim, right? So thinking about user, who feel the need for a highly secured system only very special application are relevant, applications which are expensive to maintain and, which are not maintained by guys like me, who say "oh f*** that, that is rly annoying", but more guys like "1h = 100$, nice, ty" Sep 22 '14 at 13:35
  • I thing, you're wasting your energy. I would recommend you to secure your servers themselves on system and/or network level. Securing your config files is IMO just "Tilting at windmills" or paranoia which may cost you a money. Somebody has to pay those admins... :-)
    – smrt28
    Sep 22 '14 at 13:36
  • So, now imagine I want to implement an intrusion detection system, so it has, in a way, to besigned, to work while someone has intruded your system. So i have to secure this system, just to work, on the premise that an attacker is already on the host system, right? Sep 22 '14 at 13:39

You can protect against snooping and causal attacks. But armed with a copy of IDA Pro almost anything can be done.

This is similar to the problems copy-protection and licensing solutions have to contend with. And a quick look on a torrent site will tell you how tricky it is. A skilled and motivated attacker with access to your config file and code can almost always get access.

You don't say much about the type of data. But if you want real confidence in the protection of the data I'd look to move it to another system, and not have the local machine access or read the data at any time.

Explain a little more about the data and environment and I'll refine the answer a little, because there are solutions that apply to particular situations.

For example, a typical case where this is a problem is where a desktop app needs some super-secret password for a backend server. In this case the right solution is to re-engineer the backend with individual accounts (and other controls).

Another example is where there's a local user login password. In this case the right solution is probably a one-way hash.

In other cases the Trusted Platform Module, or a hardware solution is appropriate (http://en.wikipedia.org/wiki/Trusted_Platform_Module)

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.