Storing connection strings in machine.config vs storing them in web.config

Question

For a dedicated server, is it better to store the connection string in web.config or machine.config? what's the advantages and disadvantages of each approach?

Thanks

Edit: I'm concerned about security here, so, the question is about which approach is more secure.

Answer 1

all good points. In my environment, databases are shared so storing in a web.config forces redundancy. We use standard SQL databases here that everyone accesses. A separate config file is preferred. This allows for standardizing, security and the elimination of a need to change the web.config when an app is deployed.

Answer 2

There are a lot of good points, here. JBrooks's environment is closest to mine, but in the end, I disagree with putting connection strings in Machine.config.

I agree with OJ but not for the reason he cites, here. I would point out, as JBrooks said, connection strings will very likely use different credentials in development and production environments. Our intranet development databases, for instance, all have the same set of simple credentials while our production databases each have different credentials with complex passwords. So there are very good reasons for not putting your connection strings in the Web/App.config file but rather in a file local to the target server. I like the registry, myself, but I know that's not at all supported. Clearly, the Machine.config file is there to provide a solution.

No, I agree with OJ because Machine.config resides in the .Net framework and could be changed by Microsoft. But Microsoft knows nothing of the connectionStrings.config file on our production servers. This file is loaded by Web/App.config files with:

<connectionStrings configSource="path\to\connectionStrings.config"/>

blowdart made the point about encryption--always a good idea. But in the end, the only way to fully protect your database credentials is to change them periodically.

Answer 3

I prefer to keep my connection strings in the machine.config.

My connection strings are different between the DEV, QA and PROD environments and if I kept them in the web.config I couldn’t safely blow away my target directory and copy up the new code. Or I would have to remember to deploy everything but the web.config, this creates issues when other parts of the web.config change.

It depends on your situation, but when it gets a little complicated the risk of having the wrong connection string in the wrong environment is just too great. We have actually had situations where testing was hitting the wrong databases because the connection string was inadvertently moved. Machine.config is used for machine specific items - thus the name. It never gets moved from machine to machine.

So in my machine.config I have multiple connection strings like blogConnString, forumConnString, projectxConnString, etc. I don’t consider this mixing setting for different sites, I consider it keeping machine level setting in the maching.config.

You were worried about security, I think once they are on the box they are equally secured. But if the connection string is in the web.config it usually ends up in source control, developer’s desks, in backup files, in install plans, deployment sets, etc. This makes the web.config way less secure to me.

Finally, another approach is to have it in a totally different config file (say WebEnvironment.confg), that is then referenced in your web.config. This file would sit in a directory that is not physically under your web site, but is virtually under your site. More details are HERE.

Answer 4

If security is your primary concern, concentrate on locking down the database and user permissions. The security difference between web/machine .config is minimal. Colin's answer is correct. I'd have voted up or commented there but I don't have the moxie yet!

Answer 5

security wise you could look into storing your connection strings in there own encrypted .config file that your web.config file would have a reference to.

Answer 6

I would always go with web.config on the grounds that that is where everyone would expect it to be. There is no point in giving the person that has to maintain the web site any more difficulty by storing connection strings in an unusual place.

ADDITIONAL

Based on the additional information that the OP is interested in the security aspect, rather than and general reason I've added the following.

I still wouldn't store connection strings in the machine.config. If you do that any .NET application running on the machine has access to your connection strings.

web.config is a protected file. IIS won't serve it up by default unless you do something to misconfigure it.

Answer 7

I, personally, would never store my connection strings in my machine.config file, only ever in the web.config.

You say it's a dedicated server, but is this server dedicated to a single web application?
If not, you've now got a single file (machine.config) that's effectively sharing configuration data for multiple (probably un-related) web applications. Depending upon the number of those applications, and if you ever needed to move them to another server, using the machine.config could get very messy.

Even if the server is dedicated to a single web application, you'll probably be performing your development and testing on other machines. Since the machine.config is not normally a file that's included within the file-set of a ASP.NET web application project, you will probably have to go out of your way to deploy the machine.config to each of the various dev/test/production machines, and ensure that other (non-connection string) related configuration within them is correct for that machine.

Using the web.config to store database connection strings makes perfectly logical sense and is entirely expected by almost all ASP.NET developers, even if you have multiple applications that will use the exact same database on the exact same database server. Keeping this configuration in the web.config of each application allows each of those applications to be more self-contained and not reliant upon some other "outside" file.

I generally view the machine.config and something that the framework itself uses, and it belongs on a machine and is specific to that machine. I very rarely go in and touch it myself. I view the web.config as a file that's part and parcel of your web application project and "moves around" with that project as it moves and is deployed to different machines.

Also, don't forget that a lot of what's defined in the machine.config can be "overridden" on a per-application basis by redefining certain configuration elements within a specific application's web.config file.

Of course, there are a few valid reasons to editing/changing your machine.config file (such as multiple web servers in a web farm will probably need things like encryption/decryption keys within the machine.config to be synchronised), however, I don't believe database connection strings are one of those valid reasons.