Is it safe to write connection string in web.config in an ASP.net application.
The application will be using 2 databases and I think the connection string can be retrieved easily.
Can anyone please suggest a secure place(web.config or other file) for writting the connection string except encrypting it.
Web.config is the right place for this. You can encrypt the connection string if that's a concern for you. Encrypting the connection string in Web.config it's already supported in ASP.NET and it seems that you already know that...
Link for reference.
If your worry is the outside "hackers" stealing your web.config file, then it doesn't make a difference where you store it, since if they have access to the web.config file, they probably have access to any other location where you may store the CS anyways.
If on the other hand you want to protect from an internal threat, then try saving it into a separate file (even a simple text file will do) and give that file special access permissions that only allow you and the application access and noone else. Also, you may be able to do the same thing with web.config itself.
Related
I am building a website using asp.net MVC. I have two connection strings in the web.config, one for local db and one for the server db. I am testing my work on local and then put it on the server. the server connection string (user name and password) is also in the web.config. Tomorrow when I sell the product, I want to make sure I don't give this web.config to the clients. but It can happen by mistake. How can I prevent this?
My suggestion would be to use one of two methods:
A ConnectionStrings.config or a Web.Config transform. As usual there are pros and cons for both.
Using a separate config file for connection strings
Each developer can have a local copy of their connection strings
ConnectionStrings can be marked to ignore and never committed to source control
However
- Requires each client/developer to be individually managed
Web.config transforms
Each connection string/build configuration can be source controlled
Requires publish of application rather than just a build
However
Can become difficult to maintain with large numbers of transforms.
Personally I prefer having a ConnectionStrings.config - I don't like having production credentials in source control. It also has the nice side effect of giving a build error if you've forgotten it so you can't leave them out by mistake.
Don't use user name and password in the connection string, but use integrated security.
Instead of this.
User ID=****; Password=****;
Use this.
Integrated Security=true;
And make sure your logon user has access to the local database. And the IIS server has access to the server database.
See here for configuring IIS to be able to access SQL Server.
I have used MachineKey.Encode to encrypt a ID that is getting passed as a query string to a page but as expected this is making the URL huge.
Is there a option such as HTTP handlers that could customize the url but still load the required page?
Also I am yet to find out if MachineKey.Encode is using the MachineKey that I have defined in my web.config file to encrypt the data, can anybody confirm this for me with web information that backs this up.
Thanks.
Also I am yet to find out if MachineKey.Encode is using the MachineKey that I have defined in my web.config file to encrypt the data, can anybody confirm this for me with web information that backs this up.
It does indeed use the configured keys. MachineKey calls MachineKeySection.EncryptOrDecryptData to perform the encryption, which uses encryption objects configured from the machine key section. If you want to see for yourself, the interesting calls are EncryptOrDecryptData=>EnsureConfig=>ConfigureEncryptionObject=>SetKeyOnSymAlgorithm
I am using personalization in my asp.net application. Personalization uses a connection string that it specifies in the web.config file.
Now My ConnectionStrings Section is protected and hence encrypted.
Everything else works fine without a single line of code to decrypt the connection string. But my Webpart Manager fails.
Somehow it is not able to decrypt the connection string. Now is there anywhere in the configuration manager or code that I can tell the Webpart Manager that the connection string is encrypted and that it needs to be decrypted using x encryption provider?
Please advise.
Thanks.
I just found out the answer to this question.
I was encrypting the connection string programmatically at runtime if it was not already encrypted.
We are three developers writing code. It was not running because I was encrypting it on my machine and checking it in and then the other developers couldn't decrypt it. It turns out it uses a machine specific key to encrypt it and can be decrypted only on that machine.
So if I keep a decrypted connection string in my web.config and run the code all the webparts will load correctly and everything because it would encrypt it at runtime on my machine and hence be able to decrypt it as well.
This problem won't arise in production because we will deploy the encryption code along with the un-encrypted web.config and then run the code. Once encrypted there, it will be able to decrypt it.
Thanks anyways...
I am responsible for several ASP.NET web apps running on a local Intranet server. Users outside the company aren't supposed to have access to the server, but I don't like leaving anything to chance if it's not necessary. And only admins should have access to the file system.
Should I encrypt the app settings and connection string sections of web.config? I haven't see this mentioned very often, and I was wondering if it's overkill or not a best-practice. I've got passwords in my connection strings and account info for a service account I use to query AD in the app settings.
BTW: I would encrypt using
Configuration webConfig = WebConfigurationManager.OpenWebConfiguration(System.Web.HttpContext.Current.Request.ApplicationPath);
ConfigurationSection section = webConfig.Sections["connectionStrings"];
if (section != null && !section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
webConfig.Save();
}
Should I encrypt the app settings and connection string sections of web.config?
If the connection strings include passwords: then yes, there is no other reasonable option.
If using integrated security to connect to the database, then the information exposure would be database and server names, which is less of an issue. But might be easier to have a deployment rule of always encrypting, because the simpler rule is easier to follow and audit.
You can also use aspnet_regiis.exe to encrypt sections, rather than writing your own code. Enter aspnet_regiis.exe -? into a PowerShell (or cmd) prompt to see options.
I did something similar for encrypting my web.config file, and I don't regret it. Maintaining it isn't complicated, and it adds yet another layer of defense. Since security is built in layer, there's nothing wrong in doing that.
I usually store my connectionstring in web.config or in the application settings of my Visual Studio project. The application I'm currently working on makes a lot of trips to the database which means it will look up the connectionstring every time. Should I be putting the connectionstring in the cache or should I be looking at storing the whole SqlConnection object in the cache to eliminate the need to open and close them all the time?
Update: Seems like the consensus is to store the connection string in a configuration file and leave the caching in the trusting hand of ADO.NET
I wouldn't cache the connection object, that will defeat the built-in connection pooling -- ADO.NET will handle connections (assuming you instantiate and close them) efficiently by itself.
As far as the connection string itself, you shouldn't need to cache it if you load it from connection -- the connection manager object in the .NET 2.0 framework loads the config into memory when you first access it, so there are no repeat trips to the file system.
The web.config is cached. But even if it wasn't, don't forget that ado.net maintains a connection pool - its not opening a new connection every time you make a call to the db.
I usually cache the connection string in a global configuration object in my application. This value is loaded up at the beginning of program execution from where ever it is stored -- file, encrypted file, config file, etc. ADO.NET is very good at caching connection objects to the database so I would not cache the SqlConnection object.
Keep it in a configuration file. Use a robust data access strategy provided by tools like NHibernate or Linq to Sql.
From what I can recall the contents of the .config file are held in memory anyway... I'll get back to you.
Edit: What HE said
A possible solution:
Store the initial encrypted connection string ( in Web.Config or App.Config) for a login allowed to run only one stored procedure for authentication. Than switch the login dynamically from encrypted values stored in a config table in the db.