Re: [SQL connection string security]

From: Chip Andrews (chipandrews@usa.net)
Date: 01/10/02 

Date: 10 Jan 2002 13:14:15 EST
From: Chip Andrews <chipandrews@usa.net>
To: "Eli Allen" <eallen@bcpl.net>, <focus-ms@securityfocus.com>

Eli,

I'll preface this by saying that it warms my heart to see someone take the
time to put some real thought into increasing the security of an application.
That said, I will state for the record that I have spent many long hour
debating over how to secure connection strings in applications. The bottom
line is that any attempt to "hide" the application connection string is
basically an exercise in obfuscation and only works when someone is not
determined enough to keep looking once inital attempts fail or is unaware of
the method of obfuscation (its hard to keep secrets these days). If the
application needs the string, and the string exists on the machine, then
someone with sufficient access to the machine can procure it. Placing
connection strings in the metabase is also a documented Microsoft suggestion
so nothing new there. As far as XML files go Microsoft is already on that
road as a replacement for the global.asa file.

Case in point: ASP.NET already gives the developer the ability to store
application settings (commonly the connection string is among them) in the
web.config XML file. There is already an ISAPI handler (aspnet_eisapi.dll)
that yields the following should someone request it:

This type of page is not served.

Description: The type of page you have requested is not served because it has
been explicitly forbidden. The extension '.config' may be incorrect. Please
review the URL below and make sure that it is spelled correctly.

Why is this not sufficient to protect a connection string? What makes any
other scheme MORE secure? There is always the argument that aspnet_eisapi.dll
will expose a bug or buffer overflow that will let the person gain access to
access to the file but who's to say your custom solution won't exhibit similar
problems or worse? If it is found that the handler does have a problem, you
can be rest assured there will be a patch for it and you won't have to wake
the development team to correct the issue.

Conclusion: Obfuscation always sounds good but in the end you're just giving
yourself a false sense of security. Did you fire anybody lately that knows
how and where things are hidden? Did you increase complexity of deployment to
a level that misconfigurations are now common? Is changing connection strings
now such a pain in the *** that no one does it regularly?

Do the right thing - never use SQL Server's native security. Use a trusted
connection (using the I_USR account) to a limited set of stored procedures
that control all access to the database - just like Microsoft recommends.
You'll never have the username or password lying around in a connection string
again. If someone breaksinto the SAM then you've got a lot more to worry about
than the loss of the I_USR account password. ;-)

A kludgy solution that seeks to call this - call that - look under the brick
on the front porch - and sing yankee-doodle-dandy while you turn the key
solution only works until someone sees you do it.

But keep thinking about it. I am not closed minded - I just don't want too
many people to go around chasing phantom security magic bullets.

Good luck on the job hunt. I think you've already proven your initiative and
determination to try and solve problems.

Chip
www.sqlsecurity.com

"Eli Allen" <eallen@bcpl.net> wrote:
> 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
> eallen@bcpl.net
>

Loading