views:

462

answers:

2

In my winforms application i am hashing the connection string in local level.

But here a couple of questions.

After my app decrypts the connection string, the connection string info is sent in clear text? And since my app is installed locally the man in the middle could be ANY user?

How can i protect the connection string, becides the "force encryption" option, which requires an extra certificate?

+2  A: 

you can't protect the connection string. what you can do is connect via SSL secure channel.

Mladen Prajdic
+3  A: 

You have only a limited amount of approaches here with regard to keeping your connection string safe and secure.

One option, if your connection string is stored within a web.config or app.config file (for web and windows apps, respectively) you can encrypt the value. Here's a couple of links that detail how that can be done:

Encrypting Web.Config Values in ASP.NET 2.0

Encrypt Connection Strings in VS 2005 .config Files

Of course, as you quite rightly say, this may not achieve the security that you desire, since the application may well be running on the user's machine, and thus the app.config file (even in an encrypted state) and associated encryption/decryption keys will also be available on the user's machine. A knowledgeable and enterprising user could then gain access to your "plain-text" connection string.

IMHO, one of the best ways to prevent your users from seeing your database connection string is to never give it to them in the first place, encrypted or not. This would require that your windows forms application does not talk directly to a database (using a connection string), but rather would talk directly to (eg) a web service.

Of course, you'd give the windows form application a URL with which it could access the web service, but then usage of this web service would be restricted and controlled by only allowing access with a user specific username/password combination.

This way, you can host the web service (doesn't have to be a web service - it could be a remote application that your windows form's application would communicate with over .NET remoting or WCF) on a physically separate server/machine that you do have complete control over and protect this machine with perimeter security.

It would be the applications and services that you have running on this secure machine that have access to the database's connection string, and this connection string need never be divulged outside of the perimeter of this machine, thereby keeping it completely secure (assuming the aforementioned perimeter security is in place and is effective).

Of course, implementing all of this would almost certainly mean huge architectural changes to your application, which, depending upon the size and nature of your application, may or may not be worthwhile, however, the only way to truly secure your connection string from a user (or a user's machine) is to ensure that it is never available (in encrypted or decrypted form) to the user (or user's machine).

As soon as you put the connection string on the user's machine, even in an encrypted state, you need to give that same machine that ability to decrypt that encrypted connection string, and there is the weak link in the chain and the point at which (to a resourceful user) your plain-text connection string can be determined. You could off-load the decryption of the encrypted connection string to another (secure) machine, but that's just a variation of the previously mentioned client-server mechanism whereby the part that is kept secure (decryption key, connection string etc.) is performed on a different machine under your own secure control.

CraigTP
"but then usage of this web service would be restricted and controlled by only allowing access with a user specific username/password combination."... chicken and egg problem, isn't?... you now need to hide the username/password
BlackTigerX
@BlackTigerX - I see what you're saying, but there's no reason that the username/password combo to use with the webservice needs to be hard-coded in the application (like a connection string would need to be somewhere) but could be tied into a manual authentication mechanism, the credentials for which the user would have to supply at runtime (like logging onto Windows for example).
CraigTP