views:

517

answers:

7

I have a database that I want to access via a .NET web application. I can encrypt the connection string in web.config easily enough, but any developer with access to the box can decrypt it with a few lines of code - they have access to the box, so therefore have access to the encryption key stored in machine.config.

While I can lock people out of the database by denying their user accounts access, it doesn't help that the web app has the proverbial keys to the kingdom. Anyone know of a good way to allow the web app to have access to the database without the SQL account used by the web app being available to savvy developers?

+3  A: 

If I know how a program encrypts data, and I know where are the keys, then I can decrypt data. ("I" == any developer)

Protecting the keys (Unix permissions, Windows ACLs) may stop most of them, but one can just always add a line to the program, that dumps the keys (or just the unencrypted data) to a secret place. (Or change the encryption commands to a similar-looking ones that actually are a simple XOR or equivalent...)

In conclusion, if I have control over the source code, I can make the program do anything.

grawity
+5  A: 

This is a chicken and egg problem. If your application has access to the secret (the key to encrypt your connection string), anyone running with the same rights as your application has it too.

The best way to manage this is not to have a secret at all and not to use login/pwd in the SQL Server connection string but use integrated security (SSPI). This way, your application will authenticate to the database using its Windows credentials (the account on whose behalf your application is running), without sending any credentials on the wire (regular authentication means login/pwd is passed between application and db each time you open a connection) and you don't have to store any password. You just have to make sure the password to the running account is not easily guessable. After that, you're as secure as the account is secure (which is nothing to write home about, but it's much better than having credentials passed around between processes).

Note that anything that runs with the same credential (any code in your application) will also run with the rights of the service account.

You should also limit the things the application account can do on the DB to the bare minimum it needs (no admin/dbo).

Yann Schwartz
It terrifies me that just about every project I've joined has been using the sa account to do trivial database interaction. What's worse is there's usually some esoteric, over-engineered login process in the interface.
overslacked
A: 

If you REALLY believe that your developers pose a serious security risk in the sense as you pose in this question, you should FIRE THEM IMMEDIATELY and hire developers that you can ultimately trust.

A developer that can't be trusted with the keys to your DBs should also not be trusted with the code base.

Side Note What's keeping them from DEL * . * on your file system?

Joseph
HIPPA is just one example of why you want to have hard limits on who gets passwords. It's sometimes a legal/liability issue, not just a trust issue.
overslacked
Er, HIPAA, rather.
overslacked
@overslacked That would imply that there is a difference between production systems and development systems, which in that case is easily resolved. (don't let developers have access to production environments)
Joseph
@Joseph ... too often superuser accounts are passed around at the developer level, and that inattention to security bubbles up into released versions. You're right as to how it's supposed to be done, and I agree that untrustworthy people should be fired. However, just because you can trust someone doesn't mean they should be given the keys to the castle.
overslacked
@overslacked You're absolutely right, but his question didn't say anything about different environments, so I wasn't assuming he was referring to a live environment, which I may or may not be correct in.
Joseph
Most developers don't have access to both dev and production. Politics plays heavily into these types of situations, which I think is implied to some degree, but I should have been more blatant on that point. With a solution grounded in the technology (a hard block), I can better avoid the political issue.
ddavis
+1  A: 

Although I think you may have a whole different set of issues on your hands if you can't trust your developers, you may want to check out aspnet_setreg to see if it might help.

Or you could just hire non-savvy developers. :)

Jonathan S.
+2  A: 

You might be looking at this the wrong way.

In a high-security situation, developers (just like everyone else) should not have access to the production database. You can effect this with firewalls or whatever.

If you use SSPI as Yann Schwartz mentioned, only the production web servers can get to the database. If that's not feasible, the sysadmin should manually put the (encrypted) password in the web.config file at deployment-time.

It goes without saying (or at least it should) that you should have a separate database with different authentication for development/QA.

David
A: 

Hello developers, i have a concern regarding web.config encryption. I have a shared web hosting space from an vendor & another for database at another server (The database is used for many web sites with various prefixes in table names etc).

I don't want the users of the first application server to know the details of database server (To avoid security threat to my database for many applications). I want to encrypt the connection string so that no-one see the exact details & also i don't want any developer to decrypt it as well.

So will you peoples suggest what is the best way to achieve this? Its urgent, please suggest ASAP.

Vivek Singh
A: 

The answer given here does not answer the question.

There are many reasons why one might want to encrypt the values of config files. Such as making sure the box if compromised wont then compromise the database server box.

If that database is something other than sql server such as oracle or sybase, then the above solution wont work.

There are many links here to solve this problem:

http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx

Simon