I have an MVC2 .NET 4.0 app, hosted on TFS 2008 (soon to be TFS 2010) that uses connection strings in web.config to connect to a database on another server. I need to encrypt these connection strings.
As I understand it, I can use aspnet_regiis.exe to encrypt the connectionstring portion of the web.config file, but I have to do it on the deployment machine because the encryption uses the machine name to generate the encryption key.
Now, it seems to me that this represents a problem - every time I deploy my code to the dev server won't it overwrite the web.config file, and need to be re-encrypted? This sort of manual process seems kludgy.
Is my understanding about needing to re-encrypt after deployment correct?
If so, is there some way to automate this process? I don't want to forget this or get a new team member who doesn't know the process and have the connectionstring exposed to the world.
web.config files aren't typically part of a deployment (though Visual Studio 2010 supports configuration file transforms in web application deployment projects). I wouldn't expect that you should be overwriting the web.config when you deploy (because the web.config is where you would place those things that are specific to that machine/environment.
So, encrypt it once, and then don't overwrite it, would be my advice.
Since that isn't available in your situation, it is possible to specify a key when encrypting, so that you can share the encrypted file between machines. By default, the command to encrypt uses the DPAPI to encrypt the section (which is tied to the machine) but you can also use RSA for encryption. More info is available on MSDN in Specifying a Protected Configuration Provider.
Related
I am new to web development. We are having a legacy intranet web application using ASP.NET web forms.
We have encrypted web.config using ASPNET_REGIIS tool for the connection strings, based on security feedback. I am able to test it locally using IISExpress.
What are the steps to follow to update the old web.config with new web.config, in an environment.
We need to update web.config in multiple environments(DEV,TEST, UAT) before refreshing in production.
We will be announcing downtime for the same. Please list down the steps like resetting IIS etc.
Since the key used for encrypt/decrypt is different on different server. You can decrypt the connection string section before publishing. Then just override the web.config on your target server, then encrypt the connection string with asp_regiis tool again. You can find aspnet_regiis under the root folder of .NET framework.
Of course, there is a way to sync up RSA container for mutiple servers.
https://learn.microsoft.com/en-us/previous-versions/aspnet/yxw286t2(v=vs.100)
After that, please don't forget to grant permission for machinekey file in \Microsoft\Crypto\RSA\MachineKeys.
Finally you just have to recyle the application pool.
I had to do below steps:
First and Foremost: Took a backup of existing web.config, so that, if something goes wrong, I can fallback to original web.config
As web.config encryption is machine specific, I encrypted the web.config using ASPNET_REGIIS tool, as mentioned in the codeproject Link
Web.config changes are automatically picked by IIS. I did not have to restart IIS or recycle APPPool. The site was working fine with the new web.config changes, I made.
I know I can do this to encrypt connection strings in a web site that is already deployed:
aspnet_regiis -pe connectionStrings
I can also encrypt connection strings in a web site before it is deployed by doing this:
aspnet_regiis -pef connectionStrings .\WebApplication1
I also know how to make my own RSA key, install it on several computers, and set up an encryption provider for that key, so I can encrypt it on one machine and publish it on another:
aspnet_regiis -pef connectionStrings .\WebApplication1 -prov MyProvider
I can even tell MSBuild to encrypt the connection strings for me during deployment by adding a line to the .pubxml file (https://msdn.microsoft.com/en-us/library/ee942158%28v=vs.110%29.aspx#encrypt_webconfig).
But what I really need to do is this:
create the web site source code and save it in source control with the connection strings decrypted;
build the web site, transforming the web.config file with web.debug.config or web.release.config;
encrypt the connection strings in the transformed web.config using my custom encryption provider;
and then publish it
all from an automated process. Note: I can't encrypt the connection strings first and then build the web site, because I have to transform the web.config file before encrypting it. I don't want to publish the web site first and then encrypt the connection strings, because I don't want the decrypted connection strings to be on the web server even for a brief time. I want to encrypt the connection strings during the deploy process, but with my own encryption provider. How can I do that? It's got to be possible. Any combination of msbuild commands, msdeploy commands, and .pubxml file settings would be acceptable.
I've tried searching for how to do this -- I really have -- but I can't find a comprehensive reference for msbuild.exe / msdeploy.exe / *.pubxml ANYWHERE. (That's a separate question.)
This is my first post on this forum. I have a question in regards to securing connection strings in web.config and app.config for a solution I am working on. I have a web farm with a central node that's used to push out the solution to all the servers in the web farm, this is done using a batch script.
I would like to secure the connection strings in the web and app configs on all the solutions. I know that aspnet_regiis can only be used with web.configs so it's not an option and I built a small app that secures connection strings for web and app configs but it only runs on one machine, how can I programmatically secure web and app configs in a web farm scenario? I haven't tested it yet, because I imagine it will fail, but can I just copy the programmatically secured web.config and app.config to all the servers and it will...just...work?
It will work, provided you do have the same machineKey value set for each machine.
You can set it in machine.config file in framework home directory.
I just inherited a very old ASP.NET 2.0 web application.
In the application it has SEVERAL support class library projects. In the DataAccess class library, is an app.config (and setting.settings file) with a connection string named ConnString1.
I always thought that a .DLL couldn't have a app.config/setting.settings file (or at least you can include them but they won't be used), so this is what is confusing to me.
The web.config also has a connection string named ConnString1 with the same server login credentials, but a different server name.
When I run the application from Visual Studio DEBUG, it uses the connection string that is located in the app.config/settings file, and not the one defined in the web.config/machine.config.
I thought .DLLs wouldn't do this, but use the web.config instead?
However, when I pushed this application in RELEASE mode to our production server (in test website), it seems to be using the correct connection string in the web.config.
Can anyone explain this?
There's got to be something that is confusing you to think that the config file that's a part of that DLL is being used - as opposed to the applications (entry point's) config file (yourapp.exe.config or web.config). Maybe that conn string is hard-coded somewhere for the use in debug mode, e.g. by using conditional compilation via "#if DEBUG" preprocessor directive (so, maybe search for "#if DEBUG" across your solution to see if this particular thing is happening).
MSDN article about app settings
See the yellow "Note" in the section "Creating Application Settings at Design Time": "Because there is no configuration file model for class libraries, application settings do not apply for Class Library projects."
I found the issue:
In the above example, I am using the web.config/machine.config to set the connection string for the application.
If the connection string isn't defined in the web.config, it defaults to the machine.config. If the connection string isn't defined in the machine.config, it will use the app.config setting found in the .dll.
It's important to note, that placing the connection string in the machine.config, it must be defined in the correct Framework/CONFIG.
On my development machine, the connection string wasn't defined in the web.config but in the environment.config, but in the Framework64/CONFIG -- however, the application is compiled in 32-bit, thus, the reason for using Framework/CONFIG that did not have the connection string defined in it and causing it to default to the app.config in the class library.
I hope that explains that?
All config settings must be specified in the executable config file. For windows and console apps it's app.config, for web projects it's web.config.
Libraries can specify config settings, but you have to copy the settings to the executable's config file in order for the application to be able to read them.
Difference between Web.config, AppSettings.json and App.config
Web.config:
Web.config is needed when you want to host your application on IIS. Web.config is a mandatory config file for IIS to configure how it will behave as a reverse proxy in front of Kestrel. You have to maintain a web.config if you want to host it on IIS.
AppSetting.json:
For everything else that does not concern IIS, you use AppSetting.json.
AppSetting.json is used for Asp.Net Core hosting. ASP.NET Core uses the "ASPNETCORE_ENVIRONMENT" environment variable to determine the current environment. By default, if you run your application without setting this value, it will automatically default to the Production environment and uses "AppSetting.production.json" file. When you debug via Visual Studio it sets the environment to Development so it uses "AppSetting.json". See this website to understand how to set the hosting environment variable on Windows.
App.config:
App.config is another configuration file used by .NET which is mainly used for Windows Forms, Windows Services, Console Apps and WPF applications. When you start your Asp.Net Core hosting via console application app.config is also used.
Summary
The choice of the configuration file is determined by the hosting environment you choose for the service. If you are using IIS to host your service, use a Web.config file. If you are using any other hosting environment, use an App.config file.
See Configuring Services Using Configuration Files documentation
and also check out Configuration in ASP.NET Core.
I have an existing app in production that uses SqlMembershipProvider and has a specified machine key:
<machineKey validationKey="..." decryptionKey="..."
validation="SHA1" decryption="AES"/>
It runs under .Net 2.0 AppPool currently.
I'm writing a new application that has to use the existing database, which I have a backup of. I'm trying to get SqlMembershipProvider working with it (which it does) but I can't get a known username/password working. This account works in prod, and the password hash and salt are the same on both databases (prod and mine). However at the point where the SqlMembershipProvider compares the password from the database with the hashed password entered, they aren't the same.
This article suggests breaking changes with the default hashing algorithm in ASP.Net in .Net 4.0:
http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes
However I am already specifying a machine key as suggested. Further, I've stripped out the .Net 4.0 components and dropped it back to 3.5 (which is CLR 2) and the hash of the entered password is still the same.
Furthermore, I tried redeploying this new temporary app to the same server production is on, and it still fails to login (although I can't verify if it fails due to password hash mismatch).
What else can I try here?
You need to specify the hashAlgorithmType of the membership provider in the web.config as the default has changed with .net 4.
The value that you want is most likely SHA1.
Please see the following page for more details: http://geekswithblogs.net/DavidHoerster/archive/2010/06/15/asp.net-membership-password-hash----.net-3.5-to-.net-4.aspx
First copy the production app to dev/test and run it there to see if it works as expected.
If it does, proceed to upgrade the project to run under .NET 4.0, but do not modify any other code (ie. don't try to make it work with SQLMembershipProvider) - retest the application
If that works, you know it's not an environment issue, and it's not a .NET breaking change issue, which would point to something in your code not working as you expect it should work. My guess is that the hashing algorithm you're using in the new application is different from the one being used in the old application. Were you salting the password in the old application? Are you using the same salt in the new application?