Jeff Grossman
7/25/2008 3:30:00 PM
I think the problem is a misunderstanding of DPAPI. If you use the
"machine"-based DPAPI key to encrpt your connection string, it can only be
decrypted on the machine that encrypted it. That doesn't sound like it will
suit your needs. If you use a "user"-based DPAPI key, it can be decrypted
only by someone signed in as that user, and even then, only on the original
machine unless you have enabled roaming profiles. And that doesn't sound like
it will meet your requirements either.
The underlying dilema is that your are trying to protect a shared SQL
credential. That is not a secure architecture. I see two solutions for you:
1) If your clients all reside in an enterprise Windows Active Directory
domain, your can use Windows authentication for your SQL access.
2) If not, you can introduce a middle tier that acts as a proxy for the
database connections. Many would argue this is a more sound approach anyway
as having the client tier directly access the data tier will eventually cause
you all sorts of problems.
My apologies if by "connection string" you meant something other than to a
database or if you are not using SQL Server (in which case #1 does not apply).
"Greyhound" wrote:
> I am struggling with encrypting connection strings in my Winsows Forms
> application. I am using VS2005 and I am using DPAPI to encrypt my connection
> strings in the config file. I am using One Touch Deploymnet to put my
> application out on a network drive. The problem I am having is when a user
> installs my application from the network drive, they get an error when the
> application tries to decrpt the connection string. I have been reading about
> DPAPI and I have found that it is either user or machine specific. Does this
> mean I am using the wrong encryption method for what I am trying to
> accomplish? If so, what method should I use for network installations?