0

On our product there are many config files (we have many processes)
For "logicical" configuration, we store all configuration in a document based database and then distribute the configuration to different component upon configuration change.

But, We also store configuration on app.config files, and sometimes, these files are being modified, e.g we store connection strings, ports, and other configurations.
Is there a common way to prevent End-users from playing with the app.config of a process?

The simple way is to encrypt/convert to Base64 the fields and decrypt them when loading the XML attribute, but that is a bit hacky.

Thanks

ilansch
  • 101
  • 3
  • Does it need to be kept secret, or do you just want to make it a little more challenging for end users from messing with it and wasting your time on support calls? – whatsisname Mar 04 '20 at 15:57

4 Answers4

2

Is there a common way to prevent End-users from playing with the app.config of a process?

If your process is running on a modern Windows machine and you install your application somewhere under C:\Program Files then the job is [mostly] already taken care of. Windows' User Account Control will prevent "regular" Users from changing any files under this location (and numerous others).

OK, someone with "administrative" access to their machine can still "get at" and manipulate the files but if they do so and break something well; that's really their fault, not yours. It's the sort of thing that should be covered in the Licence Agreement or Support Contract for your application.

Phill W.
  • 12,181
  • I was planning to add this to my answer ;-) So, yeah, I also thinks this is the most straightforward way to go. If the users have administrative privileges, there are no guarantees for anything... – helb Mar 04 '20 at 21:58
1

The universal rule is "you can't trust the client" even if you encrypt the strings, if the client can decrypt them so can the user.

If you need something to be secret or unchangeable you need to put it on a computer you own.

So in the case of DB connection strings, you need to have the client call an API which then connects to the DB, rather than have the client connect directly

Ewan
  • 75,506
  • our end users wont change encrypted, i agree with you, but we can add a layer of abstraction between end-users and configuration. i dont expect antivirus to block all viruses, but it will help prevent 80-90% of them? – ilansch Mar 04 '20 at 15:50
  • oh well rot13 ftw then – Ewan Mar 04 '20 at 16:04
  • Ok. So does the API need a username and password in order to call it? And if so, where do you keep that? In app.config? Doesn't that put you back in the same problem again? – Greg Burghardt Mar 04 '20 at 16:39
  • @GregBurghardt no, you can use oAuth style authentication. But in the case of SQL connections you are really trying to prevent running random commands, which the api does regardless of authentication. – Ewan Mar 04 '20 at 16:46
  • Might be worth adding that tidbit to your answer, and that you are thinking of a "web API" and not just a general purpose API in a class library? – Greg Burghardt Mar 04 '20 at 16:48
0

Encryption seems a logical solution to prevent users from modifying the configuration. But how does your application decrypt it? If you can use a built-in encryption mechanism provided by the operating system, runtime or browser (depending on the technology used to create the client), encryption is the way to go. If you instead end up with hard-coding a secret key into your application used to decrypt the configuration, other developers or advanced users will break your security measures. A normal user will probably shy away from an encrypted configuration, regardless of how safe decryption is realized.

Otherwise, don't use client-side config files. Instead, store your configuration as default values of a configuration class. Just hard-code the settings in your code. This makes it harder to change things but at least you know that there is no configuration to worry about.

helb
  • 1,390
  • "change the confiuration without rebuilding the software" what do you mean? I release some configuration with the app, e.g if i have client-server, then i put the port, if i want to change the port because it is busy on customer env, then i go to client config and server config and modify the port on both. – ilansch Mar 04 '20 at 15:57
  • Are you assuming that the client will be able to crack the encryption? – Robin Bennett Mar 04 '20 at 16:32
  • @ilansch When the configuration is part of your source code, you wouldn't have to worry about "external" config files but you would need to build the software if you want to change the configuration. – helb Mar 04 '20 at 21:56
  • @RobinBennett Yes, if things are not done right (Where do you store the secret key for decryption?) – helb Mar 04 '20 at 21:57
0

You can combine your config file with a licence key.

We have certain settings (like the number of users allowed) in a config file. A hash of that file is checked against the licence key, so if the user tries to change those settings, they'll get an 'invalid licence key' message.

This doesn't stop the users from reading the settings, just from changing them.

Robin Bennett
  • 542