I'm curious about connection string security within a network. We have a
setup with many webservers going out to a clustered DB server. Is all the
effort I put forth to secure my connection strings(whether it be DPAPI,
encrypted and stored in the registry, etc...) in vain, since at some point I
have to leave the current box, and traverse the network to talk to SQL
Server? Couldn't anyone with packet sniffing, or network monitoring tools
compromise the connection string information at that point? Is there a way
to communicate securely with a remote DB server?

Thanks,
Steve

"Steve - DND" <(E-Mail Removed)> wrote
> I'm curious about connection string security within a network. We have a
> setup with many webservers going out to a clustered DB server. Is all the
> effort I put forth to secure my connection strings(whether it be DPAPI,
> encrypted and stored in the registry, etc...) in vain, since at some point I
> have to leave the current box, and traverse the network to talk to SQL
> Server? Couldn't anyone with packet sniffing, or network monitoring tools
> compromise the connection string information at that point? Is there a way
> to communicate securely with a remote DB server?
>

Steve,
Back when I was using the SQL Server OLE DB provider, I was able
to create a secure connection from the Web Server to SQL Server machine
by adding a certificate to the SQL Server machine, then adding "Encrypt=yes"
to the connection string.
http://www.able-consulting.com/MDAC/...erForSQLServer
- see the Note section

Plus check out the following KB article:
http://msdn.microsoft.com/library/de...ar_cs_6fu6.asp

Note, I've not tried this using the SQL Server .NET Data Provider yet...

--

Thanks,
Carl Prothman
Microsoft ASP.NET MVP
http://www.able-consulting.com

"Steve - DND" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> I'm curious about connection string security within a network. We have a
> setup with many webservers going out to a clustered DB server. Is all
> the effort I put forth to secure my connection strings(whether it be
> DPAPI, encrypted and stored in the registry, etc...) in vain, since at
> some point I have to leave the current box, and traverse the network to
> talk to SQL Server? Couldn't anyone with packet sniffing, or network
> monitoring tools compromise the connection string information at that
> point? Is there a way to communicate securely with a remote DB server?

You could add an SSL certificate but it will slow down performance.
The flaw in the security design is there for a long time and will not be
fixed either I'm afraid. What you can do, if you administrate both the
webservers and the sqlserver, is this: (I assume you've followed best
practises and aren't running the machines in a domain)

- Add a new user to all the webservers, f.e. ASPNETRunner. Give it a
strong password.
- Add a new user to the machines where SQLServer runs on, and also call it
ASPNETRunner. Give it the same stong password
- Add the ASPNETRunner user as the user which is requesting/modifying data
in the database from the webservers, thus add it to sqlserver and to the
roles that allow modifying data in the catalogs used for the website.
- Use ASPNETRunner as the user which runs ASPNET and the webapplication
(site in IIS)

now you can use integrated security in your connection string, which means
you don't have to use sqlserver security, and therefore don't have to
specify a username/password in your connection string.

BUt because you have a lot of webservers, and a dbcluster, I think it is a
bit of a maintainance nightmare to add the user to all the machines.

The problem is that Microsoft has nice security guidelines but the people
designing the security models aren't reading them. I mean: you can't set
up a decent 2 box setup (db box + webserver) without a domain and WITH
integrated security unless you use the same windows user twice on each box
with the same password (and you have to remember to keep them in sync when
the password changes/has to be changed). ASPNET user, which is used to run
ASP.NET websites, is local to the webserver and unknown to the sqlserver
machine, which leaves you to use sqlserver security, something that is
'highly discouraged' by MS' security documents. Go figure.

FB

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------

> Steve,
> Back when I was using the SQL Server OLE DB provider, I was able
> to create a secure connection from the Web Server to SQL Server machine
> by adding a certificate to the SQL Server machine, then adding
"Encrypt=yes"
> to the connection string.
>
http://www.able-consulting.com/MDAC/...erForSQLServer
> - see the Note section
>
> Plus check out the following KB article:
>
http://msdn.microsoft.com/library/de...ar_cs_6fu6.asp
>
> Note, I've not tried this using the SQL Server .NET Data Provider yet...

Carl,
Thanks for that bit of information. I'm curious if it really protects
the connection string information though. Obviously it's going to secure any
data transferred once the connection is open, but I have a feeling that the
actual connection will be made unencrypted. My reasoning for this is if you
look at the Connect Timeout key of the connection string. You cannot set
this value through code anywhere, it must be specified in the connection
string, it is part of the initial setup of the connection. From this I am
surmising that even if using the Encrypt key, that the connection would be
made normally and all further data encrypted. Any thoughts on this?

Steve