不使用数据库或 .xml 文件存储敏感数据的最佳方法

Question

I'm developing an application in c# which uses an.xml file to obtain information that is used inside the logic of the app. When a new version of the app is launched, a setup is created (using Inno Setup Compiler) and after successfully installing the setup, the.xml is placed inside the setup files of the app. This.xml file contains about 200 objects with 4 properties each of sensitive data.

I got asked to launch a customer version of the app, and a requirement for this version is to remove the access or manipulation of this.xml file, since it contains sensitive data that the customer should not be able to see or manipulate.

My senior engineer told me to simply implement the information inside a list in the source code , so that the use of the.xml file is removed and the customer can't manipulate this info once installed the app, as it would be hidden inside the source code, but this seems really inefficient for me and i would need to change a lot of logic about the use of the.xml file inside the app for this to work.

1. Is there a way to create a setup of the app and hiding this file in the setup files so it cant be manipulated by the customer?

2. If there isn't, what approach could you suggest me to do? Or do i have no options but to do this the hard way?

Answer 1

If you want to make it harder for the end user to modify the information, while still keeping a separate configuration file that won't require code change of the application itself, you can sign the file and have the application verify the signature.

A simplest way is to to calculate a hash of a file and "secret" value. Of course it is hardly tamperproof. But in the end, there's no tamperproof way to prevent a user from manipulating data on his/hers own computer. It's only about how hard you want to make it.

A better way would be to use a proper certificate for the signature. The application will know only the public key and will use it to verify a signature created with a private key, which will never leave the development team.

Answer 2

From a theoretical standpoint, if your program can get hold of the data, then a user with full control of the computer on which the program is running can also get hold of the data if they try hard enough. That means you can make it difficult for them, but you can't make it impossible. So if that's what you're trying to achieve, you need to be quite clear about the limitations of the approach.

How difficult should you make it? Well, if it's purely a commercial risk, you should make it hard enough that the cost of getting the data is greater than the benefit. If the risk can't be measured in that way, for example if there are legal requirements for you to protect the data, then that isn't going to be good enough.

For some situations, it's probably enough to encrypt the XML file, and bury the decryption key deep within the logic of a compiled program written in a language that doesn't allow easy decompilation. That's likely to be better than simply burying the XML data within the compiled program, which is what your senior engineer is suggesting. But her suggestion may be OK too. It really shouldn't be too difficult to change the program logic from reading an external file to reading a string constant within the program.