There is a scriptable com object that can read from the registry which is
how WSH can read it. So it looks like that approach is the same as my first
idea just with using the registry as the storage place.

--
Eli Allen
eallenbcpl.net
> -----Original Message-----
>
> 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-----
>
> 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 ]