2

I am wondering the general convention for keeping configuration information related to the fields below for 2 concerns below:

A > Security concern

B > Update concern (in case the config should be updated by the user instead of developer).

1) I define database connection string information (database, user and password) in web.config. Is there another way i.e. keeping in cs file? I think it is impossible to keep it in the same database that application use.

2) My application send e-mail and I define the credentials in the *.cs class of e-mail. Is it true? By keeping into account that this info is changed and there is no developer to support, is it good idea to keep them in database and allow user to update them via application?

3) What is the approaches for all of the scenarios (config, update and *.cs file)? For example when keeping e-mail credentials in the database, should I get these info from database just before the usage? Or is there another approach i.e. writing it to a temporary file and then reuse it until it is changed in the database, etc.)

Any help would be appreciated.

Jack
  • 1
  • 21
  • 118
  • 236
  • I've generally moved away from storing sensitive information in my application and instead now use services to keep that for me. In my case I'm using Azure's Key Vault and then on app start, load the settings into memory. – Andy T Dec 28 '16 at 19:52
  • @AndrésNava-.NET Thanks for informing. But I do not want to use a 3rd party tool or system and I have 3 option: web.config (or another config file), database and *.cs file. Any idea for them? – Jack Dec 28 '16 at 20:00

2 Answers2

1

Keeping info such as connection strings and credentials in source code is generally a bad practice. And it is not safer than storing it in Web.config (not encrypted) because all resources can be simply extracted from code. For web applications the best practice is to store all your sensitive information in one place (like web.config) but encrypt it during deployment.

To encrypt web.config you can use aspnet_regiis tool that can be found here 

%windows%\Microsoft.NET\Framework\versionNumber

For example 

c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe

with keys -pef or -pe. You can encrypt only particular sections like <connectionString> and keep other sections not encrypted.

For more information please see Encrypting and Decrypting Configuration Sections amd How to: Encrypt a web.config File

Yuriy Tseretyan
  • 1,676
  • 16
  • 17
  • May thanks for your good answer. It seems to be good idea to keep the sensitive info in web.config. However, what if the user need to update one of the config info i.e. database name or smtp mail address? Will it be possible to update them in the encrypted web.config file? On the other hand, what do you think about keeping them in the database except from the database connecting string? – Jack Dec 28 '16 at 20:19
  • 1
    Usually it is done by continuous integration server (CI). You just change your `web.config` and commit to repository CI does encryption and deploys to prod. However, you can do this manually on prod server by decrypting web.config, changing it and encrypting back. Before CI we did that using powershell scrtipts. – Yuriy Tseretyan Dec 28 '16 at 20:21
  • 1
    You can use db to store config and it is usually normal but you may face some difficulties problems during application lifecycle, for example releasing and rolling back your changes. – Yuriy Tseretyan Dec 28 '16 at 20:25
  • 1
    Another argument against database is that it become a point of failure. If you don't have connection to database (it is down) you would prefer to send a message to developers or to support or at least perform minimal functions that do not involve database. In this case you will have to have many places where config stores. In my opinion, all configuration that does not change dynamically or by user, should be kept in `web.config` or some config file. – Yuriy Tseretyan Dec 28 '16 at 20:35
  • Can we say that all of the configuration i.e. that is changed rarely i.e. database connection, etc. should be kept in web.config after encryption. And the other config that might need to be updated sometimes i.e. smtp settings can be kept in database. Is that a good idea? If so, could you please an example or example page except from msdn (really very bad documentation). – Jack Dec 28 '16 at 20:48
  • 1
    Yes you can, but I would store in database either user's specific settings or something that can be changed frequently or settings that you change sometimes and you do not want to re-deploy your application because of them. User @user783836 gave a good link to step-by-step guide. Copy it here http://stackoverflow.com/questions/26294226/encrypt-and-deploy-app-config – Yuriy Tseretyan Dec 28 '16 at 21:25
  • Voted+. But if I keep the config's database name, user and password in the database how can I reach to this database? And if I decide to keep all the config, haw can I do that? Any approach or sample page? Regards... – Jack Dec 28 '16 at 21:39
  • 1
    It is not possible to keep config to database in database, it has to be in web.config's `connectionstrings` section. For `smtp` client configuration there is a special section too (See: http://stackoverflow.com/q/19233108/1437693). Another settings you can keep in `appSettings` (See: http://stackoverflow.com/q/8147220/1437693) or you can create your own class that introduces a section (See: http://stackoverflow.com/q/2155/1437693) – Yuriy Tseretyan Dec 28 '16 at 21:43
  • Many thans for your perfect explanations. – Jack Feb 01 '17 at 10:08
1

It's generally a good idea to encrypt sensitive application configuration data. There are a couple of approaches available to you, depending on what kind of application you have.

For web applications, you can use the DPAPI and aspnet_regiis to encrypt the configuration. See Encrypt and deploy app.config for sample code.

Alternatively (if you have a desktop application or don't want aspnet_regiis) you can have a look at protected configuration sections as described here: https://msdn.microsoft.com/en-us/library/hh8x3tas.aspx

To answer your specific questions:

1) Keep it in the web.config and encrypt it. Hardcoding in a .cs file is flawed from a security perspective (code can be decompiled) and it will make it difficult to change as your code moves from environment to environment (dev -> uat -> prod)

2) Again, don't store credentials in a .cs file. You can provide a UI for users to manipulate config but remember that they may break the config and you'll need a mechanism to restore to a known good config

3) If you are concerned about how often you read from the db (although reads are cheap as long as there are no writes) you could simply read all the config into a class on startup. That way there are no temporary files to manage and the amount of reading on the db is limited.

Community
  • 1
  • 1
user783836
  • 3,099
  • 2
  • 29
  • 34
  • Many thanks for the nice explanations. I have an ASP.NET MVC Web Application and need to be clarified a little bit more about the following points... >>> – Jack Dec 28 '16 at 20:12
  • **1)** As you suggested, I will keep all the config info in web.config file by encrypting them via **aspnet_regiis**. However, what if the user need to change a database name or mail smtp address in the config file? Will it be possible to update these info if they are encrypted? **2)** I am thinking about to create a page for updating smtp mail settings. So, could you please post an example for showing that: the config data is retrieved from database and load into a class file. Then how can ı use it in mail sending class? **3)** Should I encrypt the config data before saving to database? – Jack Dec 28 '16 at 20:15
  • If you have time please clarify me about the points in my comment above? – Jack Dec 28 '16 at 22:16
  • 1
    1) generally the config file shouldn't be updated by the application. you can move those settings to a db 2) I would assume you have some MVC-type framework in place for generating the page. You can then either use dependency injection to inject your config, or have your config as a static class you can reference 3) depends on your security requirements - what is being stored and who can access it. Sometimes I do, sometimes I don't. – user783836 Dec 29 '16 at 06:08