I have a distributed wpf application that I am trying to find a good way to encrypt the connection string in the app.config. I have tried renaming the app.config to web.config and running the aspnetiis_reg from the command line, that encrypts it but I later found out that only works for the user running the command, I have gotten code online that reads the connection string and encrypts the password and saves the app.config, and when running the application I can run a function that decrypts the password and saves it but that leaves a gaping whole that someone can locate the app.config and see the password when running the application, also you would have to know when the application is closed to go back to encrypt it. Can someone tell me the standard way to encrypt the password and decrypt at runtime with out having to write extra code on a WPF application. To note, I have migrated this application to enterprise library 5.0, the prev version was 1.0 and there was a way of putting the connectionstring in a separate file and encrypting and letting ent library or .net decrypt and not have to worry about it from their. what I was hoping for was a similiar way of just encrypting during build if possible an have .net decrypt without writing extra code for different cases
You can refer to app.config part of this msdn document. There is also code samples there.
Related
(Sorry in advance, if I have the wrong tags)
Hello!
So I am trying to work on a personal WPF project which would allow the client application exe to download another application exe (Unity Application) and open it within the client exe's Grid. Everything is working fine.
But, I am wondering if there's a way to "lock" the downloaded application in a way that only my client exe can open the downloaded exe?
Here's the only solution I have thought of but not sure with
Check for command line arguments within the Unity Applications
This works well but people who knows about the existence of decompiler might be able to decode that I am trying to check the arguments, and input relevant data there. :(. So, it won't help too much?
Thanks for any insights.
-Kevin
There is no non-hackable solution, you can only make it harder for crackers to break into the app by code obfuscation (hard to read the code) + adding integrity checks (make sure that your app is not modified).. There are commecial apps out there to do this (ex. PreEmptive), and their solutions differ from each other, nothing is ultimate.
Anyway, You might make Unity Application read some file or some registry value that Client application has updated just before launching the Unity Application, along with command line args method that you mentioned..
I have a problem with my WPF application (a simple clicker game). I've just made a deployment/created a setup project using Microsoft Visual Studio Installer Projects extension for Visual Studio. Everything seemed to work fine, setup works good (tested on other computer) and furthermore the installed application almost works correctly. The only exception is a button calling function which is creating a new txt (something like a draft of a "save" file) file in a folder where the application is installed. Clicking this button cause instant crash of the whole application. Nothing else happens, no error message, the app just turns off.
I assume that the problem lies in access rights to the folder/administrator rights.
I've added txt file with the same name in the application folder using "File System" window in setup project, deployed and installed again. Even when the file exists the problem happend again (probably because of access rights when trying to override file content).
It's may be important that everything worked while running app through VS, also using .exe works fine on any computer. The problem is only with application installed using setup.
I'm not sure where the problem is so it's hard to show some code, to be honest i'm not even sure if it's a problem with code, maybe it can be solved with setting some setup project properties?
I would like to store some data locally between two sessions, i've choosed txt file because it's light and simple even if it's not the most elegant way.
I expect that installed application will be able to create and override txt file in it's folder.
P.S. if you need any code, screenshots or information about my setup please let me know in comments section, I will provide what's necessary
At the moment you install your program you're having administrator-rights. So the folder where your application is, also was created with administrator-rigths.
If you want to store data to this folder, you'll have to run your application as administrator. (not the best idea)
Otherwise you can change your code to write your file at runtime to a different location where you don't need administrator-rights.
For example:
string path = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
will give you: "C:\Users\MyUserName\AppData\Local"
string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
will give you: "C:\Users\MyUserName\AppData\Roaming"
string path = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
will give you: "C:\Users\MyUserName\Documents"
And some error-handling around the saving of the file would be very nice and helpful ;)
Thank you everyone for solution and knowledge, the problem was as I assumed (access to the path denied).
I was using this code to create a path:
Directory.GetCurrentDirectory() + "\\SyntyhCitySave.txt";
Creating a file in a special directory instead of application folder works, that's the solution for my problem:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) + "\\SyntyhCitySave.txt";
Tomtom answer marked as accepted.
I currently have a C# Application that is a distribute, and that multiple people have. I was wondering which approach could I take to hide the app.config file (.exe.config) file that is produced after a build, So that the users cannot see my connectionstrings to my remote server. I read somewhere that If I encrypt the file, It can only be decrypted on the machine It was encrypted on, which means that It would not work for the other computers that the application is on, It would only work on my PC. Which approach could I take so that The config file can be hidden / obfuscated / encrypted, or anything to protect the config file, But without it being specific only to my computer, that can actually work for any one else who has the distributed version?
Any help would be appreciated, Thanks
Do not ever give a credential to someone if you don't want them to be able to use it. It really is that simple. You cannot both give a credential to and withhold a credential from the same entity. Whatever security checks you need to do, do them on your machine. That way, even someone who has the connection strings cannot bypass any security check you care about.
If you are worried about exposing addresses of other machines you might want to consider putting these machine behind a router machine.
This way client machines and their users only know about the proxy and the remote machines would only have to be open to and trust the proxy.
Even if you encrypt the config file:
the machine will need to decrypt the file to use the connection information so the secret is out any way
using a network sniffer the user can always see to what machines his machine is connecting.
I'm creating a program in VB.Net that heavily interacts with 2 large MSSQL databases. I do not know a ton of vb and I'm fairly new, but I would assume just having the connection strings in the code and releasing the program it would be quite easy for someone to reverse the program and get my connection info? correct me if I'm wrong.
My question is I'm wondering if there is a safer way to use a connection string in my program. Would I just have to encrypt my app? Create a module or dll?
You can encrypt just the portions of the .config file which contain the sensitive material, in this case connection strings.
The answer is aspnet_regiis.exe
The location may vary depending on your system and version of .NET, but a file search should narrow it down.
Let's say you have a program called myapp located in c:\dotnetaps\myapp.
I use the following command to encrypt the "connectionStrings" portion of web.config:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pef connectionStrings C:\dotnetapps\myapp
Wait a second: web.config is only for web apps, not local ones, right?
aspnet_regiis.exe only works for web.config, but the format is exactly the same as app.config. Therefore, all you need to do is rename app.config to web.config, run the tool, and rename it back. A little awkward, but nothing that can't be automated by a batch file.
# Encrypts connectionStrings in app.config
ren C:\dotnetapps\myapp\app.config web.config
path\to\exe\aspnet_regiis.exe -pef connectionStrings C:\dotnetapps\myapp
ren web.config app.config
Important note: Using literally these commands will encrypt the file against the particular system it is running on. You'll want to do a little reading to get it to encrypt against a key that allows you to distribute your code, but this is the general idea.
You could store it in your resources file (MyFile.resx) as an encrypted string.
I'm creating a regular windows application that will be distributed to several users on my department. I'll need to include some connectivity passwords on the App.config file, and I obviously don't want end-users to just fire up notepad and look at the passwords.
Several articles point on how to encrypt/decrypt configuration sections, but it appears you have to share/ship some keys with the deployable solution.
Is there a simpler way, to just cipher some of the settings so that they are not user-readable, but that don't require extra steps or files when redistributing the program? Great plus would be that accessing the configuration settings is still transparent inside the .NET code. I could always just create a custom method to salt/cipher the string and in my custom code decrypt it, but I'm wondering if there's something simpler.
Any answers or links to articles on how to do this are greatly appreciated. Thanks
If you are trying to encrypt your connection string in your App.Config/Web.Config, you can do so using the Configuration class:
Configuration config = ConfigurationManager. OpenExeConfiguration(ConfigurationUserLevel.None);
ConfigurationSection section = config.GetSection("connectionStrings");
if (section != null)
{
if (!section.IsReadOnly())
{
section.SectionInformation.ProtectSection ("RsaProtectedConfigurationProvider");
section.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Full);
}
}
There are two methods: RsaProtectedConfigurationProvider and DPAPIProtectedConfigurationProvider
See this --> http://www.codeproject.com/KB/cs/Configuration_File.aspx and http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx.
In short, cryptography isn't a magic wand that can magically fix an insecure program.
An attacker will try to obtain passwords from memory using a Debugger while the application is running. The passwords will also exist in the binary and these can be easily obtained. The use of any encryption can be bypassed because the password must be in plain text at the time of use. Any time memory is used it can also be observed with a debugger.
The answer lies in anti-debugging: http://www.codeproject.com/KB/security/Intro_To_Win_Anti_Debug.aspx
More advanced windows Anti-Debugging:
http://www.veracode.com/blog/2008/12/anti-debugging-series-part-i/
http://www.veracode.com/blog/2008/12/anti-debugging-series-part-ii/
http://www.veracode.com/blog/2009/01/anti-debugging-series-part-iii/
http://www.veracode.com/blog/2009/02/anti-debugging-series-part-iv/
Either way, the encryption and decryption of the application configuration file is pointless as the .EXE can be examined by Reflector!
Sure you can obfuscate the code but that will make debugging a nightmare in a production environment where a strange unknown/undiscovered bug crept in as you would not be able to tell what/where/why/how to monitor for a strange bug that will only show up in release as the stacktrace and error messages would be obfuscated also...
That is something to bear in mind about and a potential pitfall...the user may not be tech savvy, but sure they could in theory, ask a friend/relative/partner to hack/break it without your knowledge..This answer is not meant to put you off, and hope you don't feel offended by my answer...
Hope this helps,
Best regards,
Tom.