Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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??

share|improve this question
2  
Of course, you could just have the application run as a domain user and only allow that user to access the database. Then they need access to LDAP to break into your database. –  pdr Nov 8 '11 at 23:05
    
@pdr: the connection string will still reveal some info that you would prefer not to be revealed if the webserver was compromised, e.g. the name of the database server and the name of the database. –  Carson63000 Nov 9 '11 at 2:57
add comment

3 Answers

up vote 13 down vote accepted

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.

share|improve this answer
    
Test is binary, binary is numbers, if somebody can read the 1's and 0's your physical and software security has failed. –  Ramhound Nov 9 '11 at 15:12
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
You should never have a password in clear text in a config file. Just because it is an enterprise application behind firewalls doesn't mean it is safe and you can forget about security. –  Ryan M 2 days ago
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.