I want to encrypt my "ConnectionString" settings which is located in app.config.
But at the Runtime, I want to use( read ConnectionString ) it directly, without decrypt it.
I mean, I don't want to anyone to decrypt the string. There should be NO decryption method.
I'm thinking; it should be like embed .net/asp.net/iis feature to use.
Like "Windows Login" ( you can enter it, use it, but you can't decrypt )
===
An Example Usage; You have small website with some critical data.
You have no money to buy private server,
so you are working on shared server, if the server hacked somehow,
you application and database will be stolen.
But if you put encrypted connectionstring in app.config,
This will be hard to decrpt it and see what is inside in Database.
Encrypting and decrypting configuration settings in a config file can be done from the command line using the aspnet_regiis.exe tool.
The details are described in the following MSDN article:
Encrypting and Decrypting Configuration Sections
As the tool is mainly intended to be used with Web applications, it expects the config file to be named 'web.config'. This means that you temporarily will have to rename your app.config file to web.config:
rename App.config web.config
aspnet_regiis -pef connectionStrings . -prov DataProtectionConfigurationProvider
rename web.config App.config
DPAPI might be a solution.
You can connect your usr/pwd/credentials to the machine. JGalloway knows more about this than I. JGalloway knows more about anything dotnet than I.
http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx
If I haven't mixed things up this creates a usr/pwd combination that is bound to the very hardware of the machine. I.e. change network card and stuff might break. Also; one cannot create the usr/pwd/creds one machine and then transfer to another. In short this means that you have to do whatever you have to do on the production machine - might give you a headache if you are targeting continuous delivery.
Caveat: I haven't tried it myself. Instead I opted for a "regular" encryption. If someone got hold of my encrypted string and bytecode and reverse engineered it I would be smoked. But it was enough of security for me.
Related
I have an encrypted password in a connection string, contained in a web.config file. I do not know what the password is, and thus cannot connect to my database.
I ran aspnet_regiis.exe -pdf against the web.config and received the following:
Decrypting configuration section...
Succeeded!
I guess I had assumed that the password would be displayed on the screen, or something close to that? Then I thought the program might create a log file with the information in it? Couldn't find one.
I know I am missing something fundamental, I just don't know what it is.
You cannot decrpty the encrypted password.
The whole point of encrypting the password is so that no one is able to decrpty and find what the password is unless you know the key.
When you encrypt the connection string, the key is automatically created and stored in the machine where the encryption was done.
So, if you copy the web.config file to some other machine and do the decryption using:
aspnet_regiis.exe –pdf “connectionStrings” YourPathToWebConfigFile
This won't work.
And to answer your question, if the encryption and decryption was done on the same machine, then your web config file will change automatically with the plain text (decrypted data) for connection string , not that the password would be displayed on the screen.
Run below command
aspnet_regiis.exe –pdf “connectionStrings” C:\inetpub\wwwroot\MyApplication
C:\inetpub\wwwroot\MyApplication needs to be the path where your web.config file is. Once you finish executing above command check your web.config file. If it worked OK you will have decrepted connection string section.
Before I begin, I've done good bit of research and googling. I think I didn't find the perfect answer because I'm probably a noob :)
However, I've created a POS software using Windows C# form application and it's working perfectly fine. Now, this application is using MySQL as database server.
I've been hard-coding the database server credentials on app.config file.
Code for the app.config file :
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="cString" connectionString="Server=localhost;Database=adittoenterprise;port=3306;Uid=root;Pwd=root123" providerName="MySql.Data.MySqlClient"/>
</connectionStrings>
</configuration>
Now I'm trying to create a package for other users to use. Definitely I need to come up with solution where the user can provide
host
username
password
During the installation and the application should store this somewhere (that is where my knowledge is lacking) and use it on the run time.
Any alternative solution is most welcome.
Thanks everyone in advance for bearing with me and helping me :)
Your installer needs to modify the app.config file. There are many different types of installers available and some of the more fully-featured packages can modify XML files such as app.config during installation.
It's also possible to modify the connection string at runtime (though since it's an application-scope setting, not a user-scope setting, that's probably not a good idea) as long as you do it before any database objects attempt to use it:
Properties.Settings.Default["cString"] = "new connection string";
... so you could potentially distribute your app.config with a blank connection string and prompt the user to provide those values the first time the application is run. You'd have to save the new value into a user-scope setting, though, in order for Save() to work:
Properties.Settings.Default.CustomConnectionString = "new connection string";
Properties.Settings.Default.Save();
(Note that I am a computer science student and still learning)
EDIT the links are not useful for your case as they only work with IIS, but still I would not save passwords in plaintext to a file such as the other answer suggested.
It should be considered bad practice to save the password especially plain text. Usually if an application starts it would require the user to authenticate to get access to the database. Of course you can store the password, but doing that properly you should look at http://msdn.microsoft.com/en-us/library/hh8x3tas.aspx and http://msdn.microsoft.com/en-us/library/89211k9b%28v=vs.80%29.aspx
Then if your application start for the first time your application can create/edit the config file and store the values. Note that your application cannot change it's own app.config at runtime so it would make sense to create a web.config for you database connection.
I am very new on c#/Visual Studio and I'm having difficulty on running my test methods. It requires us to connect to a database server resulting of getting always a failed result since we can't connect to the database.
We tried to modify the connection string to include our working credentials so that we can connect to the database server but the app.config file was encrypted.
Please see below screenshot of example encrypted line. How can we modify that?
As I see it I think the connectionstring is encrypted outside the project and pasted here. I am saying this because IMO encrypting just the connection string value and keeping the key in plain text is not possible from within the project. It is possible to encrypt the entire section within a config file.
Check the method which is using this connectionstring. I believe The method might be using some form of decryption. Use that to decrypt the string, change the values as required, encrypt it again and paste it in the above location.
You can also edit your question to include the method which is using the connectionstring so that I can analyse it and give you a better solution.
Hope this helps.
How do I get the ConnectionString from the app.exe.config at runtime when the app.exe.config has been encrypted?
When you are on the SAME machine and used the standard encryption methods you can access the connection string just like it has never been encrypted.
ConfigurationManager.ConnectionStrings[]...
You just can't move the config to another machine. Always encrypt on the machine where you want to decrypt it.
Consider the following Link with Code Sample...
http://www.codeproject.com/Articles/186234/Encrypt-Net-Configuration-file
Good Luck!
I have a requirement to protect my Web.config file from malicious users accessing our webserver & junior developers in team. I have used RsaProtectedConfigurationProvider to successfully encrypt & decrypt our file. However, decypting the connection string is as easy as accessing it from withing my application, no matter if it is encrypted or not
protected void btnShowConnectionString_Click(object sender, EventArgs e)
{
lblMessage.Text = WebConfigurationManager.ConnectionStrings["MyTestConnection"].ConnectionString;
}
How do I secure my connection string to avoid work arounds like these?
You cannot do this with standard solutions.
To do such protection you should write your own wrapper around standard library using this connection string, that will decrypt connection string from webconfig.
And you should protect your wrapper from decompiling with something like Sentinel Hasp. If you don't protect your wrapper it will be simple to get encryption algorithm and decrypt connection string.
But it will be simpler to do not write production connection strings to developers webconfig. Use developer enviroment for developing and write production enviroment connection strings when deploying to production enviroment.
You can read this link about secure string connection, recommended solution by msdn
link : http://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx
IMHO, the "workaround" you are mentioning isn't really a workaround, rather, it is what it is.
Your application (web or otherwise), must be able to decyrpt the information so that i can actually make the connection. Unless you are using Windows Authentication to your SQL server, user/pwd are always "there"...the nagging question I have is why/how would such code exist in your application (in the first place)?
As noted above in previous answers, separate your development environment from production - perhaps only have production config transforms in production environment.