Is it a good practice set connection strings in a web config?

Question

Recently I have a discussion with some of my colleagues at my work because they said that it's better have in a .DLL a string connection encrypted. And I said why just don't use the string connection defined in the web.config encrypted? it's the same and it's better because entity framework, for example looks for the name of the connection in the web config of the application, Now i want to know from a security point what's better or what's the best practice??

Answer 1

There's no substantive difference, except that you'll have to actually build a binary if you wanted to make a configuration change if you put it in a DLL, whereas an admin could just modify the configuration with well-understood off-the-shelf tools if it's in the config. There's already a mechanism for encrypting configuration strings and additional guidance on MSDN. Current versions of Asp.Net may have alternative mechanisms, so do some additional research before committing to an approach.

Just because something is sitting in a DLL, doesn't make it any more secure. A text editor can open binary files just as well, tools like Reflector can provide a nicer interface to navigating a .Net DLL; a DLL won't provide any "extra" encryption.

Answer 2

It doesn't matter where the encrypted data is stored, it matters how it's encrypted.

Encrypted sections in an web.config are normally encrypted with the Data Protection API, which is extremely difficult to crack without compromising the entire machine. You can also use an RSA key container, which is similar (difficult to get those off the machine).

If you want to store the encrypted string in the DLL, that's fine, I guess, although it's not inherently any more secure than an encrypted web.config (anybody can peek into that DLL with Reflector), and is obviously harder to change (you'd need to recompile). But again, what's a lot more important is how that encrypted string was generated; presumably you're not using the same providers as you would for an encrypted web.config, so what are you using?

An encryption scheme is only as strong as the private key or shared secret. If that key is also stored in your assembly, then you might as well have no encryption at all. If it's stored in some external database, then it raises the question of how that database's connection string is secured. This can really only lead to weaker security overall.

On the other hand, if you were a service provider and the connection string were encrypted with a user password, then that would be more secure than using a static machine key. Then again, if you're using user passwords to encrypt, it's pretty unlikely that you'd be hard-coding the encrypted data in your assembly, since it needs to be generated and stored in response to user (not developer) action.

Really I can't think of too many situations where hard-coding an (encrypted) connection string in the DLL is any more secure than encrypting the relevant web.config section. At best it's just adding inconvenience, at worst it's relying on some clumsily-written custom security riddled with holes. Do yourself a favour and do what Microsoft recommends - just encrypt your web.config if there's sensitive data in there.

Answer 3

The best practice for ASP.NET is put all configurations/settings in the web.config file or app.config file (for other project types).

About encryption and the reason to use it on your connection strings have to be a very special case. Because most cases up to 99% you don't need to encrypt your connection strings. Microsoft own enterprise applications have their connection string exposed in the web.config/app.config file. I think you are over complicating security.

One more thing, hard-coding your connection strings is bad practice. For instance, do not put any connection string (aka connectionstring) in a DLL or .aspx/.ascx/.cshtml or code-behind.