We've had a basic premise for storage of connection strings, ODBC DSN passwords and the like. If we are not using windows based authentication (most times we do not, as it's not very portable between database back-ends) we will almost always store the connection strings in the system registry. We'll then build a com object to read the registry keys and obtain the connection strings. This keeps that information out of the readable file-system. For an attacker to gain access to the key, they would have to ,basically, completely compromise the host webserver. We use appropriate permissions on both the registry keys themselves (along with the obscurity of an attacker having to locate them), and the com objects that are capable of reading them. So, this means either gaining the system account permissions, administrative permissions, or the permissions of the web-server's executive account is required to gain access to the connection string. If any of the above three things happens, it's pretty much game-over anyway.

-----Original Message-----
From: Eli Allen [mailto:eallenbcpl.net]
Sent: Wednesday, January 09, 2002 8:18 PM
To: focus-mssecurityfocus.com
Subject: SQL connection string security

With the importance of not letting the connection string used to connect to
a DB out (i.e. not putting the connection string in the source file) I had
two basic ideas on how to do that:

http://www.wam.umd.edu/~eallen/sqlconnstr.html

__
Eli Allen
eallenbcpl.net

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]