Again: Protecting ConnectionString in web.config

[bigMAC]

Hi,

Today, i met a problem from my boss: how to protect the connection
string in web.config
if there's a cracker gain full control of the win server that IIS
located?

At first, he said plaintext is unacceptable. After some searching, i
reported some
solution:

I said store it in registry, my boss ask: he can read it though
regedit

I said the encrypt/decrypt connection string method that widely found
from
Internet, he ask: if cracker trace the program, he can property
decrypt it programmetcialy. The same, hardcode the string in a dll is
also
banned.

I said window auth of sqlserver 2000, he ask: if cracker gain full
control,
this is useless.

After that, i counter: if a cracker gain full control of the server,
any protection
is already useless.

He said: IIS is easily being attack, so we must think of such a
situration.

At last, i want to ask: why you choose ASP.NET that must bind on IIS
even you
have such concern????? but i had not.

I m not trying to talk about the vulnerablily of IIS, but this is real
talking
from my boss.... anyway, any solution or comment on this silly
conversation
are welcome.


Thank you very much

 

[Chris Jackson]

The most secure way is to use Windows authentication, so you don't have a
connection string.

If you must use SQL Authentication, then look into the command line utility
aspnet_setreg, which will encrypt and store in the registry (using strong
ACLs) the connection string.

The bottom line: the aspnet_wp process must be able to decrypt the
connection string if it intends to pass it. If your box is compromised to
the point where the attacker can do anything the aspnet_wp process can do,
then they can read it, but that goes without saying. The only way to prevent
an attacker who has compromised a system to that level is to not have
anything valuable stored at all. So, you can mitigate the damages by having
that connection string provide you with only the access that you need for
that one application to run. Denydatareader and denydatawriter, and give
execute permissions on only those stored procedures that you need to access
to make the application run, so the attacker can do nothing more than make
the application do what it would be doing anyway.

 

[Alek Davis]

Check out the article "Safeguard Database Connection Strings and Other
Sensitive Settings in Your Code" at
http://msdn.microsoft.com/msdnmag/issues/03/11/ProtectYourData/default.aspx.
It may give you some ideas.

Alek