How to Secure Passwords Stored Inside Web.Config

How can I secure passwords stored inside web.config?

Generally, web.config is a secure file and IIS does not serve it, therefore it will not be exposed to users who are making requests to web server. Web server only serves specific type of files and web.config is surely not one of 'em.

Quite often you save your database connection string in it which includes password. Now imagine an scenario where web.config was not secure. You have created a major security threat to your application.

Therefore, specially as long as your project is not too big, you should not be worrying about it.

Yet, you may have a better approach but creating a project called "Resources" and save all the critical information such as settings, consts, enums and etc in there. That would be a slick and organized approach.

If you are passing the username/password over the wire though (for example in case of a secured API call), you may want to use https to make sure that information that are travelling are encrypted but that has nothing to do with the security of web.config file.

Confused on what is the correct procedure on storing passwords in Web.config for Azure deployment

I find the following technique to be the easiest way to do this.

Instead of putting the deployment values of these settings into the web.config, I keep the test values in there instead. I then put the deployment values into the Application Settings section of the Azure Website via the Azure Portal:

Sample Image

When the website runs, these settings will take precedence over what is in the web.config. This helps me avoid externalized files, allows me to keep sane development configuration that the team can share, and makes deployment very easy.

The & character breaks passwords that are stored in the web.config

I suspect that you didn't encode the password properly in the web.config file. Remember that web.config is a XML file, so entities must be encoded.

Instead of

my&password 

try

my&password

You can use sites such as FreeFormatter.com to escape/unescape XML strings.

Encrypting appSettings in web.config

  • Encrypting and Decrypting Configuration Sections (ASP.NET) on MSDN
  • Encrypting Web.Config Values in ASP.NET 2.0 on ScottGu's blog
  • Encrypting Custom Configuration Sections on K. Scott Allen's blog

EDIT:
If you can't use asp utility, you can encrypt config file using SectionInformation.ProtectSection method.

Sample on codeproject:

Encryption of Connection Strings inside the Web.config in ASP.Net 2.0

How to securely use credentials outside web.config for ASP.NET & Azure

First I would turn the customErrors off so you can find the real problem, but my guess is that you aren't including the AppSettingsSecrets.config in your solution. This will cause a problem once deployed because the file isn't there - so you should remove the configSource or file attributes from the config using a web.config transform.

So in the Web.Release.config you can add the following inside the:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
...
<connectionStrings xdt:Transform="RemoveAttributes(configSource)"/>
<appSettings xdt:Transform="RemoveAttributes(file)"/>

When you do a publish of the release build, this will remove those file paths from the config so it won't fail at startup once deployed.

Update

Now you'll need to add all the appSettings that were in the AppSettingsSecrets.config file to the appSettings in the portal. This will keep your published site credentials only in Azure.

All The appSettings in the Web.config and any other files get merged into the same listing (meaning your code doesn't need to know the appSetting is coming from the web.config, AppSettingsSecrets.config or being configured from the azure portal. Here is a good article on appSettings: https://buildazure.com/2015/11/30/azure-web-app-application-settings/

The good things about your setup is:

  1. the AppSettingsSecrets.config has the secrets needed only for
    developers and is not included in source control or published
  2. the published site credentials are only in Azure and available to
    only those with access to the Azure account.


Related Topics



Leave a reply



Submit