VS 2005 publish and app.config encryption problem

  • Thread starter Thread starter Craig Banks
  • Start date Start date
C

Craig Banks

I'm using the publish capabilities of VS2005 to deploy a smart client
application. To secure the connection strings I'm encrypting them in the
app.config file using the DataProtectionConfigurationProvider. Everything
works fine with one major security hole I need help with.

My client is set up to encrypt the app.config when it loads. So when a users
installs the smart client application from the publish.htm web site VS 2005
sets up, it forces an application load and happily encrypts the
myapp.exe.config file that's deployed to the local machine. The problem is
when the smart client application is installed it also makes a copy of the
myapp.exe.config file in a second directory that appears to be used for
storing application culture which is not encrypted.

For example, the 2 folders might look like this:

c:\Documents and Settings\User\Local
Settings\Apps\2.0\myap..tion_2d04e939dd17e942_0000.0009_e3eea666c5a3367a
<---Encrypted
c:\Documents and Settings\User\Local
Settings\Apps\2.0\myapp.exe_2d04e939dd17e942_0000.0009_en-us_b62a96f4cbfdf23e
<-- Plain text

Any suggestions? Please, no friendly advise to simply switch to Windows
authentication to SQL Server - I don't need to go there.

Thanks.
 
Hi,

i have no idea about the two config issue.

But from whom do you want to protect the connection string?? If the app can
encrypt it (running under the user's security context) the user can easily
write a little app (well - he could even use the aspnet_regiis command line
tool) to decrypt the setting.

If you know that this is simply security through obscurity - i am ok with
that - but don't rely on this feature to provide real protection.
 
It's going to local Intranet/network users. But you have a good point. The
public key is stored on the user's PC, I believe. An alternative I'm looking
at is encrypting passwords encrypting a separate XML file containing
connection strings. In that case, the key is stored inside the code which,
of course, can be disassembled. So am I buying much security over just
embedding a password in code (generally considered poor programming
practice)?

I went with my current approach because it's Microsoft's recommended
alternative over Windows authentication.

Unfortunately, unless I'm missing something, Windows authentication is less
secure for us because granting users read/write access that way will allow
them to bypass our application by using some tool like Access to link to SQL
Server tables. The fear here isn't that users are hackers who will
maliciously alter data but that they'll accidentally mess stuff up because
they currently use stuff like Access for their own ad hoc reporting needs.

I may be missing something but .Net Smart Clients using SQL Server appear to
me to be inherently insecure.
 
Back
Top