Thread: Web.config Encryption does what?

Can some explain what exactly the encrypt process is supposed to do.

I have ran the config wizard on my development site and received the message that it ran. The security audit warning me to encrypt web.config is gone, but I notice I am still required to have web.config at the root level of my site or it will not run. I am still able to open this file and read everything. I see it makes a new file with a newcfg extension. How do these files interact with each other?

Encrypting the web.config should render a few sensitive pieces of information (EncryptKey, DBConn, etc) unreadable in case someone manages to get ahold of that file. After that's done the file will still be readable for the most part, but there should be a <cipherdata> section that has a bunch of 'random-looking' characters in it where that data used to be.

Well, as far as I can see it from the wizard.aspx.cs itself. It will not create another file but instead will encrypt the appsettings tag values which contains the keys of your private information:
EncryptKey, DBConn, DBSQLServerLocaleSetting, DelayedCustomerCreation, SiteDownForMaintenance, SiteDownForMaintenancePageLocalizationFormControlP roperties and change them into EncryptedData/CipherData/CipherValue. But the web.config file is still there...

If I check the web.config file I still see in "clear text" the connection string and all other data that is supposed to be secured during the encryption process. The new file that is created contains the <ciperdata> section that was mentioned. I do not see how this secures anything as someone can still open the web.config file.

The security audit shows that it ran and I did not get any access denied messages during the process, but I would think the <cipherdata> entry should be in the web.config?

I am using ML/64 8.0.1.2

This shouldn't be the behavior by default. Encryption process shouldn't write a new file, if this is so, it defeats the purpose of encrypting the web.config; hence, the procedure should overwrite the existing one. Could you please post the
if (AppLogic.TrustLevel == AspNetHostingPermissionLevel.Unrestricted) block of your wizard.aspx.cs. Let's start from here.

There are two blocks which I will paste below. There are two files that were created during the encrypt process. et3eohbx.newcfg and et3eohbx.tmp. et3eohbx.newcfg is an exact copy of web.config with the exception of the cipherdata section it contains.

in loadData()

Code:

if (AppLogic.TrustLevel == AspNetHostingPermissionLevel.Unrestricted)
            {
                Configuration webconfig = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
                AppSettingsSection appsettings = (AppSettingsSection)webconfig.GetSection("appSettings");
                rblEncrypt.Items.FindByValue(appsettings.SectionInformation.IsProtected.ToString().ToLowerInvariant()).Selected = true;
            }

in btnSubmit_Click

Code:

if (AppLogic.TrustLevel == AspNetHostingPermissionLevel.Unrestricted)
            {
                string encyptionprovider = AppLogic.AppConfig("Web.Config.EncryptionProvider");
                if (encyptionprovider != "DataProtectionConfigurationProvider" && encyptionprovider != "RsaProtectedConfigurationProvider")
                {
                    encyptionprovider = "DataProtectionConfigurationProvider";
                }
                Configuration webconfig = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
                AppSettingsSection appsettings = (AppSettingsSection)webconfig.GetSection("appSettings");
                if (rblEncrypt.SelectedValue.Equals("true", StringComparison.InvariantCultureIgnoreCase) && 
                    !appsettings.SectionInformation.IsProtected)
                {
                    appsettings.SectionInformation.ProtectSection(encyptionprovider);
                    appsettings.SectionInformation.ForceSave = true;
                    webconfig.Save(ConfigurationSaveMode.Full);
                }
                else if (rblEncrypt.SelectedValue.Equals("false", StringComparison.InvariantCultureIgnoreCase) && 
                    appsettings.SectionInformation.IsProtected)
                {
                    appsettings.SectionInformation.UnprotectSection();
                    appsettings.SectionInformation.ForceSave = true;
                    webconfig.Save(ConfigurationSaveMode.Full);
                }
            }

This is really strange. Those lines should be okay. Anyway, could you set a breakpoint on the btnSubmit_Click event, then check the runtime value of the Request.ApplicationPath, then proceed until webconfig.Save(ConfigurationSaveMode.Full); and constantly checking on the File path. I'm sure that configuration class is being thrown off somewhere forcing it to create another file. Let's try this.

I think this issue is coming from permission conflicts. As I previously stated the security audit that warns about the config not being encrypted was gone after running the wizard yesterday. I just logged into the site this morning and found it was back.

I was running several tests yesterday to find the permission settings to get rid of an access denied message on web.config. What I found was that I could not just set NETWORK SERVICE at the root level. I ran into similar issues with the product import feature awhile back and remembered that I had to enable IIS_IUSRS permission to the file. So I added IIS_IUSRS to the root level and ran the wizard and it finished without access errors. I think both were maybe conflicting with each other, but still allowing the wizard to complete.

I went in this morning and cleared out the permissions and set only IIS_IUSRS to have access to mod/read/write...etc and then ran the wizard. It completed and I do not see any of the temp files laying around. I also see the cipherdata section in web.config now.

The server environment is Windows Server 2008 and IIS 7 with compat mode.

Yup, that's the case. The Configuration class will create another copy of the file but will not tamper the original because the permission specified is not correctly mapped. Anyway, I'm glad you've sorted it out. By the way, please revert back your permission on the web.config to Read-Only for security purpose...