How do I prevent users from modifying my data files?

Question

I am working on a project that will replace outdated software on our production floor. One of my problems is that currently configuration files, script caches, etc. - all this is plain text stored in the system that the user uses. Many of these things will be pushed aside to restrict network access, but things like configuration files remain local. This is already a problem when users think that they know what they are doing with the system, and changing the configuration files. I do not want this to happen in the new software. How should I prevent this? Encryption? Do some signature / checksum with database lookup? What features does C # /. NET offer to help me with this?

UPDATE:. To solve some of the things that were mentioned in the comments, each user on the production floor has administrator access to the system they are working on. This is unlikely to change in the near future, since most of the security is associated with restricting access to folders on the network, web services, and databases. Permissions would be ideal, I agree, but I have to work in the environment that they provide me. I plan to bring it to the meeting that I have with IS to find out if this is possible, but suppose it will be on a system where the user has full access.

Answer 1

This is not a problem with C # encoding, this is a problem with the system configuration. Configure the machine so that users have regular (non-administrative) accounts. Set file permissions in the configuration files that you are worried about so that anyone (including your application running as the current user) can read configuration files, but only the administrator can write configuration files. Finally, do not give users an administrator password .; >

If your application also needs to write configuration files, you will need to add code to enter administrator mode in your application, preferably only around the write operation.

Answer 2

To prevent the average end-user from manually modifying configuration files, you can simply sign the configuration file using the SHA of its contents combined with some secret factor known only to the program. This is obviously not a real or perfect secret, but it is enough to prevent uninterrupted end-user intervention.

Basically (pseudo code):

function isValidConfig(configPath, signaturePath) { return readFile(signaturePath) == SHA(readFile(configPath) + secret) } function writeConfig(contents, configPath, signaturePath) { writeFile(configPath, contents) writeFile(signaturePath, SHA(contents + secret)) } 

Except for decompiling the program, they will not be able to change the configuration. I assume that you do not have l33t crax0rs on your production floor ...

Answer 3

The option is that you can move as much as possible from the configuration file either to Isolation or even better to the database. It would be unlikely that the average user would know how to access them.

Answer 4

I would save the files in some kind of structured storage, whether it be isolated storage, a slightly encrypted ZIP file or something like our SolFS virtual file system (also encrypted). The second advantage of having a single file is that it can be easily backed up for backup.

Answer 5

This seems like a good job for digitally signing. A digital signature will ensure the integrity and authentication of your data. The digital signature value will determine whether the data (configuration file) has been changed and that the data has been obtained from a reliable source. A digital signature is created by performing a data hash and then encrypting the hash with the private key from the public / private pair. The application decrypts the encrypted hash, computes the data hash, and compares the decrypted hash with the computed hash. If the hashes match, the data is valid. If they do not match, the data has been changed.

.Net contains these functions in DSACryptoServiceProvider.VerifyHash

Of course, if you don't want to sort through the problem of creating a public / private key pair, you can just go with a simple hash of the configuration file to make sure it has not been changed.

A really important question: what are you going to do when the application detects a modified configuration file?

Are you going to close the application, block certain functions, send you an email, try to get a good copy of the configuration file? These actions are called the integrity check penalty. Right now your application does not perform integrity checks in the configuration file, but when you add the verification, you will need to choose the best way to fail.

Answer 6

I am not an expert in local security, but perhaps you can use file system permissions to prevent access to this folder or file.

Then, if your application needs to access this file, you will need to start the application with a different Windows account, which has the right to modify the file.