I know that you have to right click on the solution and go to the bin folder from where you can copy the .exe, dlls and the config file and share it to end users. The issue is that I am storing my database connection code in the appconfig file which has database username and password also. So, if I share the appconfig file to the end user, it will not be secure as any unauthorized person can gain access to database and do anything. Plus any user can modify the appconfig file easily by opening it using notepad . Is there any other way to achieve this ?
Resolved How to share a .exe file to the end user ?
- Thread starter Anonymous
- Start date
-
- Tags
- .exe app.config deployment
Skydiver
Staff member
Just like the way the web.config in ASP.NET apps can be encrypted, you could also encrypt the app.config. The encryption is transparent to the running code so you don't need to change your code. You'll need to jump through some hoops to perform this encryption, though, because there are no built in tools in the SDK to perform this encryption for desktop apps, unlike ASP.NET apps which have regiis.exe which let's you do the encryption. It's not difficult to build up your own tool to do this. Just inconvenient.
So the upside is that this is the most secure way to do what you want because each encrypted version is per machine/per user specific (unless someone has been illegally cloning machine). The downside on top of the need to create your own tool, is that you have to perform the encryption either at install time or first run. So your secrets still need to be delivered to the user unprotected until you get a chance to protect it.
Anyway, why is the desktop app accessing the (shared) database directly? If the database needs to be secured, then put a web service in front of the database and have your app authenticate against the web service and send it's queries to the web service. Then at that point the only secrets stored on the machine are the per user secrets needed to logon to the web service. Each user should have their own credentials for auditability.
Then it'll be the users responsibility to keep their credentials on their own machine secure. You could likely help them out by doing some on the fly encryption and decryption of their credentials in your app.config using either DPAPI built into Windows (the more secure route), or just use some of the symmetric encryption built into the .NET Framework. For the symmetric encryption, the problem then becomes how to secure the key you use for the encryption.
So the upside is that this is the most secure way to do what you want because each encrypted version is per machine/per user specific (unless someone has been illegally cloning machine). The downside on top of the need to create your own tool, is that you have to perform the encryption either at install time or first run. So your secrets still need to be delivered to the user unprotected until you get a chance to protect it.
Anyway, why is the desktop app accessing the (shared) database directly? If the database needs to be secured, then put a web service in front of the database and have your app authenticate against the web service and send it's queries to the web service. Then at that point the only secrets stored on the machine are the per user secrets needed to logon to the web service. Each user should have their own credentials for auditability.
Then it'll be the users responsibility to keep their credentials on their own machine secure. You could likely help them out by doing some on the fly encryption and decryption of their credentials in your app.config using either DPAPI built into Windows (the more secure route), or just use some of the symmetric encryption built into the .NET Framework. For the symmetric encryption, the problem then becomes how to secure the key you use for the encryption.
Actually, I have no control over the database and currently the customer doesn't have any webservice. My desktop application is updating the database. One option I thought that I could do is to store the connection string in the class file rather than in appconfig file but my appconfig file will still have log file tags and other tags which my application is using. When I will share the .exe, I will also share the dlls and config file. It is very much possible that any user might open the config file, might change it and might crash the application. Is there any other way I can share the .exe ?
Skydiver
Staff member
What are you trying to prevent: changing the connection string, or prevent the user from seeing the connection string?
If all you need to prevent is the user changing the connection string, then just hard code the string into your code (despite this not being considered a best practice).
If you are preventing the user from seeing and changing the connection string, then you'll need to encrypt the connection string somehow. It could be a simple as ROT13, XOR, or something more secure.
Depending on what type of code obfuscator you use, you can potentially store the connection string hard coded into your code to make it difficult (but not impossible) for the user to see and change the connection string.
If all you need to prevent is the user changing the connection string, then just hard code the string into your code (despite this not being considered a best practice).
If you are preventing the user from seeing and changing the connection string, then you'll need to encrypt the connection string somehow. It could be a simple as ROT13, XOR, or something more secure.
Depending on what type of code obfuscator you use, you can potentially store the connection string hard coded into your code to make it difficult (but not impossible) for the user to see and change the connection string.
Skydiver
Staff member
I hope your client has the database only open to his LAN and not exposed naked to the Internet.
Yes, I will integrate the connection string to the code as they will be distributing the application to end users. If I keep it in config file, then any end user might see all the connection info and then can access the database to make any kind of changes !!!
Skydiver
Staff member
Since you are working in a LAN and presumably distributing over a LAN, take a look at ClickOnce deployments. With ClickOnce deployed apps, the files are buried in a relatively obscure directory that a user will have to actively go digging for.
Similar threads
- Question
- Question
