9

I have a bunch of .Net config files which contain passwords for Windows service accounts and/or SQL server logins. I would like to get them out of the config files and keep them more secure.

What is a good alternative to having the passwords in the config file?

Thanks

Matthew MacFarland
  • 2,413
  • 3
  • 26
  • 34
  • 1
    One common technique is to store the password in the configuration file as an encrypted string – FoggyDay Feb 12 '15 at 01:56
  • 2
    You can keep the passwords in the file, but store the encrypted version of the password. Even if you were to store the passwords somewhere else instead of a config file, they should be encrypted. – PaulMcKenzie Feb 12 '15 at 01:57
  • 3
    That just shifts the problem. How do you unencrypt them? – Oliver Charlesworth Feb 12 '15 at 01:59
  • @Oliver Charlesworth - that's a stupid reply to a very big question. The fact is, sometimes it's perfectly appropriate to encrypt portions of a configuration file - or even the entire file. There are many, many ways to do this. By the same token, there are alternatives to storing *any* usernames and/or passwords in a configuration file. For example: https://msdn.microsoft.com/en-us/library/ff650785.aspx. BOTTOM LINE: There's no "one right answer". IMHO... – FoggyDay Feb 12 '15 at 02:09
  • 1
    @FoggyDay - which reply are you saying is stupid?. You've suggested the OP replaces a secret with a different secret, without alluding to how this could be done! – Oliver Charlesworth Feb 12 '15 at 02:14
  • 2
    The correct answer is going to depend entirely on where you place the balance point between convenience and security. Only after you define that point can a reasonable answer be given to this question. – Sam Axe Feb 12 '15 at 03:22

5 Answers5

7

I have to disagree with the given answers here. Assuming that your program requires to start up without someone entering a password, the program needs access to some clear text credentials in any way. If you encrypt the config file, where do you put the key to decrypt that config file? Encrypting the config file doesn't make anything better, it just makes the administration harder, with no noticeable improvement in security.

In the end you have to rely on the security of your machine holding that credential. Harden it as good as possible, restrict access to it as good as you can.

There is a longer article on that elaborating more on that fact.

Michael
  • 7,316
  • 1
  • 37
  • 63
  • Encrypting asyncrounus does indeed works without entering the password every time (priv-key) The server/app could generate a RSA key-pair with itself keeping the private key (or hardcoding it. And publich the public key eg. saving it in a file. In this case everyone can create a encrypted password but no one except the server can decrypt it – Niton Jul 21 '20 at 11:34
  • I can't follow your logic. The server has to store it's part of the key and doesn't know the clients secret, yes. What you call public is actually the private key from the client point of view. And the question was, how to store such private keys securely. All I said about storing secrets holds true. – Michael Jan 30 '21 at 10:59
  • Yes but the decryption key could at least be hidden in the server code and obfusecated. But yes you are right because in the end of the day its just "security by obscurity" – Niton Feb 03 '21 at 04:31
  • The technique shown on [MSDN](https://learn.microsoft.com/en-us/aspnet/web-forms/overview/data-access/advanced-data-access-scenarios/protecting-connection-strings-and-other-configuration-information-cs) uses a legacy config encryption utility, which, when using RSA containers, stores the keys in such a way that only specific AD accounts have access to the decryption keys. This to me appears to be more secure than custom encryption techniques. – Victor Romeo Oct 26 '22 at 03:44
5

You can actually encrypt sections of your config files. it's not "separate" from the config file as you asked about in your question, but it is more secure than storing the unencrypted/plaintext passwords in your config file.

Example to encrypt the connection strings (from command prompt):

aspnet_regiis -pe "connectionStrings" -app "/SampleApplication" -prov "RsaProtectedConfigurationProvider"

Note that this same technique can be applied to sections aside from connection strings.

See the tutorial at: https://msdn.microsoft.com/en-us/library/zhhddkxy%28v=vs.140%29.aspx

To decrypt and encrypt a section of the Web.config file, the ASP.NET process must have permission to read the appropriate encryption key information. For more information, see Importing and Exporting Protected Configuration RSA Key Containers.

The application will be able to use the encrypted values natively, but if a user had access to the config file say via a fileshare, the strings would still be encrypted.

Another tutorial which might have some additional info: http://www.codeproject.com/Tips/795135/Encrypt-ConnectionString-in-Web-Config

Note that encryption is reversible with the appropriate key. Your safest bet would be to lock down remote and share access to the area where the config file is stored. Without either of these, your config file shouldn't even be accessible to anyone but administrators to the server.

Kritner
  • 13,557
  • 10
  • 46
  • 72
  • 1
    This doesn't answer the question. Also, anyone with access to the server can just decrypt the config file and get the passwords. – Jason Kelley Mar 19 '18 at 18:19
  • 2
    If someone has gained access to your server, you have already lost. There is nothing I am aware of that you can do at that point. – NDevox Mar 20 '18 at 15:39
1

No one told about using service account + trusted connection !

Pushpendra
  • 820
  • 7
  • 11
0

It's not certain if you are referring to desktop applications or if you are referring to web applications. If the former, then I'd say you definitely should be encrypting the passwords in the config file.

If you are referring to a web application, then you also have the option of encrypting the credentials and saving them in the registry using aspnet_setreg. Then you reference your registry location in your config file.

This also makes it easy to have different credentials in different environments, without changing your config file. For example, in your sandbox environment you have your sandbox credentials encrypted at the following registry key: HKLM\SOFTWARE\MY_SECURE_APP\, but on your production servers you have a production ID encrypted to that same key.

Jeremy Pope
  • 3,342
  • 1
  • 16
  • 17
0

I would take a look at the Data Protection API : MSDN Windows Data Protection

Also see related question: How secure is ProtectedData.Protect (DPAPI)?

Paul Arnold
  • 439
  • 3
  • 7