7

I've had a very frustrating experience on putting an MVC 5 app on Azure. I have been reading the following page: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure

But what I haven't managed to put in my head is the following:

Security Warning: Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.

And:

Security Warning: Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.

The problem is the following: When I upload the Web.config file with the external files without being included I get hit by "The System cannot find the file specified", so for it to go away I must include the .config files defeating the purpose of Microsoft's post.

I really really really do not understand. I have added the connectionStrings and appSetting's keys in Azure's portal. What is the correct and secured way of putting my passwords and secrets online? What am I missing? Is it because I'm running in Debug mode?

According to this: How can I secure passwords stored inside web.config?

There is nothing to worry about accessing the Web.config file...

But that just defies Microsoft's post.

Thanks.

Community
  • 1
  • 1
Jose A
  • 10,053
  • 11
  • 75
  • 108

2 Answers2

3

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:

enter image description here

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.

Brendan Green
  • 11,676
  • 5
  • 44
  • 76
  • Close, but you can even use the Connection Strings section instead of the App Settings section in order to better secure your secrets – Zain Rizvi Oct 13 '15 at 22:56
  • See what you mean, but I don't think there is all that much additional security to be gained here, and now you have the added confusion of reading non-connection string settings from the connection string section of the config. – Brendan Green Oct 13 '15 at 23:00
  • Thanks for the reply. In case of the connection strings... Will it matter if I have only the localdb connection on my machine and on Azure I configure the DB connection? Will the DB connection supersede the localdb? I remember reading that the connectionStrings are overridden whereas the App Settings are merged or replaced (in case duplicate is found). – Jose A Oct 14 '15 at 00:20
  • 1
    Same mechanism applies to connection strings as it does with app settings. That is they are merged, and any setting that exists in both the portal and the config file is overridden by what is in the portal. – Brendan Green Oct 14 '15 at 00:34
  • @BrendanGreen Do you use web.config transforms to remove the test/local values from the config files so any secrets (for example app settings that contain api tokens) don't get pushed to Azure? – Matthew Feb 27 '17 at 03:33
0

The best way is to set your secrets in the Connection Strings section of the portal. Any values set there will override values you specify in your web.config file.

This way they are only exposed to people who have admin access over the site itself. Having full access to the source won't even be enough to get the secret values.

enter image description here

More details here

Zain Rizvi
  • 23,586
  • 22
  • 91
  • 133