What's the best way of storing (configurable) application settings.

Question

I'm developing an application that has a few dozen settings, which have a default value at installation time, however they may be changed at execution time.
The settings will not be set by the application directly itself, instead it provides an API which independant client applications can use to change the settings.
One client will be a debug/test GUI to view and set the settings.
Another client will be a sort of monitoring program that is able to receive setting updates sent to the device by some mechanism (i.e. HTTP or OTA etc.). When it receives the setting changes it will call the application API to change the settings.
My first question is
- in general what is a good mechanism for storing these settings? (The settings are small things, numbers etc.)
- if the settings are stored in a file or database etc., how can they be made tamper-proof from malicious programs, i.e. is it possible that the only program which can change the settings is my application?
- if my application is the only program which can directly change the settings, that's not secure if any malicious client can access my application's API. Therefore is there a mechanism whereby an application can police usage of its API to a known list of clients?
Thanks

Answer 1

niuniu wrote:
- in general what is a good mechanism for storing these settings? (The settings are small things, numbers etc.)
Configurable settings are generally stored in a property list file (.plist). E.g. see Storing Dictionaries in the NSDictionary reference.
- if the settings are stored in a file or database etc., how can they be made tamper-proof from malicious programs, ...
In general, there's no such thing as tamper-proof. You need to decide on a level of security based on how important your program is and the consequences of a security failure.
- if my application is the only program which can directly change the settings, that's not secure if any malicious client can access my application's API. Therefore is there a mechanism whereby an application can police usage of its API to a known list of clients?
I guess you could require clients to logon in some fashion. But protection against an entity with knowlege of your API and the ability to install a malicious client requires a level of security far above what you've asked about so far. Simply identifying the client in this scenario is a little like securing a water heater against a 9.0 earthquake when we expect the entire building to collapse at 7.5.
For example, a priori I would look at your network input long before I would consider a malicious, local client.
I would suggest defining your security requirements in terms of what kinds of attacks you expect and how far you're willing to go towards a defense. At that point one of the security experts around here might be able to recommend some specific solutions.
Btw, the subject line of this thread doesn't reflect the more difficult security questions you're asking. A more accurate topic description makes the forum easier to search, and also gets the attention of the right experts. So if you don't get the kind of help you need, you might consider a new thread about data security.
\- Ray