2

I have an ASP.Net Core website running on IIS. I need to store some passwords that the site needs to access in production. No paid password storing systems are available to me. I chose to store my passwords in environment variables. So on the production machine I have:

  • a service account my_prod_service_account
  • an application pool MyProdAppPool that runs under my_prod_service_account
  • a website MyDotNetCoreSite that runs in the MyProdAppPool

Approach 1: Normal Environment Variables

I login to the production machine as my_prod_service_account and set environment variables for this user in Powershell:

[Environment]::SetEnvironmentVariable("Pwd1", "MyPrecioussss1", "User");
[Environment]::SetEnvironmentVariable("Pwd2", "MyPrecioussss2", "User");

After this MyDotNetCoreSite can read these environment variables.

Approach 2: system.webServer\aspNetCore Environment Variables

Something similar can be achieved with %WINDIR%\system32\inetsrv\config\applicationHost.config (IIS configuration file) on the production machine. It can be edited manually or through UI, but in the end it looks like this:

<configuration>
    <location path="MyDotNetCoreSite">
        <system.webServer>
            <aspNetCore>
                <environmentVariables>
                    <environmentVariable name="Pwd1" value="MyPrecioussss1" />
                    <environmentVariable name="Pwd2" value="MyPrecioussss2" />
                </environmentVariables>
            </aspNetCore>
        </system.webServer>            
    </location>
</configuration>

After iisreset MyDotNetCoreSite can read these values as environment variables.

Question

I want to change my password storage method from Approach 1 to Approach 2. The former sets environment variables per user, the latter per site (which I think is neater). But I can't find enough documentation to judge whether Approach 2 has the same level of security as Approach 1. Setting a "normal" environment variable stores it in the registry at HKEY_Users\my_prod_service_account SID\Environment\Pwd1. Accessing the registry usually requires elevated permissions, and if someone breaks into it, we will have bigger problems than hackers knowing Pwd1. Is applicationHost.config as secure as the registry? Can I confidently store a password in it?

Ari Linn
  • 207
  • 4
  • 11
  • If you don't know yet, passwords for application pool identities are stored in applicationHost.config, though encrypted, https://learn.microsoft.com/en-us/iis/manage/configuring-security/using-encryption-to-protect-passwords – Lex Li May 01 '20 at 01:33

1 Answers1

0

I can just give some head-scratch questions/concerns:
I am curious, have you done a set in a command line and checked if any unwanted passwords are listed in the output in plaintext?
Also, if you store all passwords in one file like in Approach#2, this makes a nice honeypot. I do not know how well the encryption works, Lex Li mentioned.

Antares
  • 605
  • 3
  • 14
  • 1
    obviously if I login as my_prod_service_account and do a `set`, it will list all passwords in plain text. But this requires either hacking my_prod_service_account or an admin account who can access the registry and see everyone's environment variables. – Ari Linn May 01 '20 at 14:33