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...
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.
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.
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
My application is on the shared Hosting.I've encrypted my Connection String programmatically to make it secure. However, the hacker still is able to decrypt the encrpted Connection String adding scripts into the DB.
Just wondering if there is a way to solve this problem? Many thanks !!!
.NET vulnerability discovered last September.
Make sure your .NET is up to date!
If the hacker gains control over your server, he can do anything your code can do. Can your code decrypt the Connection String? (apparently yes) Then he can do it, too.
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.