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.
Related
The title almost says it all, but I'll provide a little background.
I am working on adding password hashing to a program written by a team member who rather suddenly departed this world. I have all of the original source, and have made appropriate changes.
The issue arises when, after looking at the active connections on the database, the connection it is making is under my Windows Activate Directory username, rather than the connection string I give to SqlConnection().
I am not traditionally a C# programmer, but the language is very easy to pick up on. For those more accustomed to C#'s particular ins and outs, what can I do to assure that I'm connecting through the connection string passed to SqlConnection()?
This is important since people who are not me and have no authorization to the database are not going to be able to even validate their DB stored usernames + password without using that connection string.
EDIT: My current connection string is as follows:
user id=[uid];password=[password];server=[server];Trusted_Connection=yes;database=[dbName];connection timeout=30"
Trusted_Connection is an alias for Integrated Security, which means "use my Windows account". Remove it from your connection string.
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.
I am using Visual Studio 2010 and Microsoft Access 2010 to develop a desktop application using C# programming language.
connection string is:
connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data
Source=|DataDirectory|\KBank.accdb;Persist Security Info=False"
and i give it the password in the C# code as follows:
public string GetConnectionStringByName()
{
string returnValue = null;
ConnectionStringSettings settings = ConfigurationManager.ConnectionStrings["Info_Bank_Project.Properties.Settings.KBankConnectionString"];
if (settings != null)
returnValue = settings.ConnectionString + ";Jet OLEDB:Database Password=blablabla";
return returnValue;
}
i have used the database in the project in just one simple "Select" query.
so, concerning to the security issue..
can any one decrypt the access database or see the password?
and what is your suggestion to make it hard for any one to see the database data
This is little old thread, My experience on this issue might help someone.
You can create C++ DLL with the strong password located inside it, then call it from C# app to encrypt/Decrypt methods with the data base file name.
No, your data is not safe, since anyone can inspect your code using an MSIL decompiler and retrieve your connection strings from your app. There will be a point at some point in your process where someone has the possibility of seeing that password, whether it's in memory, in reflection, or something else.
If you have data that is in the possession of someone other than you, not on your servers, then you can assume you no longer have control over that data.
Now, with all that said, you can make it harder for them to get to by encrypting the database file and obfuscating your code.
Why not just put the password in your app.config and encrypt the app.config.
See here
I created a desktop application in C#/WPF which connects to a SQL Server 2008 instance through a constant connection string specified in code as follows (for testing purposes):
private string GetConnectionString()
{
//test
return "Data Source=[server IP]; Initial Catalog=[database name]; User ID=[user ID]; Password=[smart password];";
}
The application will be used by various users and will be deployed via ClickOnce, a .zip archive or a custom installer. It also has a separated custom login functionality by requesting an application-access username and password.
Which is the best practice to store the connection string details for my desktop application (IP, database, SQL Server user, password)? If the connection string changes over night, which is the best method to update it without forcing users to update to the latest version of my application? Users should not be able to see/intercept/decompile the connection string, so I guess I must use some sort of encryption.
Do you have any kind of suggestion for my inquiry?
Even if you compile your connection strings into the application, they still can be viewed using the Ildasm.exe (MSIL Disassembler) tool because strings are a part of assembly's metadata.
Maybe this question can help you.
In a desktop application, you can't prevent a determined user from seeing the connection string. Even if you use encryption, a determined user will be able to find and use the encryption key.
If the client is connecting to the database then the connection can be hacked.
This is a sample of connection data in App.Config
<appSettings>
<add key="dbServer" value="svr"/>
<add key="dbDataBase" value="db1"/>
<add key="dbUser" value="sharedUser"/>
<add key="dbPassword" value="easyPassword"/>
</appSettings>
Need a reference to system.configuration
string SvrName = ConfigurationManager.AppSettings["dbServer"];
string DBName = ConfigurationManager.AppSettings["dbDataBase"];
string DBUser = ConfigurationManager.AppSettings["dbUser"];
string DBPassword = ConfigurationManager.AppSettings["dbPassword"];
As for security the answer is a 2 tier application where only the secure server side code connects to the database. This code sample from server side code.
The other benefits of server side is repeated queries from the same connection can gain from indexes in memory from prior query.
You could salt and hash the password read from the AppSettings and obsfuscate the application but you would have to use a static salt so it could be hacked. It would just slow down the hacker.
You need to add an "Application Settings" file to your application. Just right click on your solution -> add -> find something similar to "app configuration". In order to do this you will need some kind of external config file to store the connection string. You could even use a simple file. If worried about people finding the file, you can always encrypt the string and decrypt it in your app.
My opinion is that the safest solution is to have a local DNS entry point to the current SQL machine and the authentication to be Windows authentication.
For example : SQLMACHINE host name pointed to 192.168.1.3 in the DNS server.
This way if the name/IP of the SQL machine changes, only the DNS server needs updated (and possibly the local DNS caches to be invalidated).
Having Windows authentication means that no password will be stored on the local machine so you can safely store the connection string in the .config file with no worries.
My 2 (euro)cents.
I'm working on my first real WinForms application, and my boss has asked that I figure out a way to encrypt the connection string inside the app.config. I've read some of the suggestions in other questions about connection string encryption, and I recognize that it isn't a silver bullet answer to the security/privacy problem. We've considered writing web services to retrieve data from the database, but this is a very small project and unfortunately isn't a priority at this time.
Edit: I left out the detail that I'm working for a state institution (community college) where, because we're identifying students using a state-mandated private system ID, we need to secure the application in some form or fashion. Students may enter their network IDs to identify themselves (which we need to protect anyway as some students have restraining orders and need much of their records kept private), but many students only know their system IDs (which are always kept private).
Regardless, we'd like to get this process working in conjunction with ClickOnce deployment, but my encryption process crashes the application when I run the ClickOnce executable. Here's my encryption code (which is lifted from another question here on SO):
public static void EncryptConfigSection(string sectionName)
{
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
ConfigurationSection section = config.GetSection(sectionName);
if (section != null)
{
if (section.IsReadOnly() == false &&
section.SectionInformation.IsProtected == false)
{
section.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider");
section.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Full);
}
}
ConfigurationManager.RefreshSection(sectionName);
}
I'm calling this function from the Main() function in Program.cs, but I'm not sure if this is the appropriate place for it. Additionally, while this function encrypts the app.config correctly, as soon as I exit the application, the app.config decrypts. I feel like I'm missing a piece to the puzzle (or perhaps large swaths of the puzzle).
Can anyone offer me some insight into these problems? I'd like to reiterate that I recognize that web services are the end goal here, so if this is just not a solvable problem using CLickOnce, then I'm willing to suggest that we prioritize writing web services now.
Have you looked at this topic? It talks about setting up the client using DPAPI so the string is encrypted. I would still look at the web services route rather than embed a connection string, encrypted or not, into a client application. This is ESPECIALLY true if you are talking about client apps outside of your domain (ie, non-employee use).