Are there more secure alternatives to the .Net SQLConnection class?

Question

Hi SO people, I'm very surprised this issue hasn't been discussed in-depth:

This article tells us how to use windbg to dump a running .Net process strings in memory.

I spent much time researching the SecureString class, which uses unmanaged pinned memory blocks, and keeps the data encrypted too. Great stuff.

The problem comes in when you use it's value, and assign it to the SQLConnection.ConnectionString property, which is of the System.String type. What does this mean? Well...

• It's stored in plain text
• Garbage Collection moves it around, leaving copies in memory
• It can be read with windbg memory dumps

That totally negates the SecureString functionality!

On top of that, the SQLConnection class is non-inheritable, I can't even roll my own with a SecureString property instead; Yay for closed-source. Yay.

A new DAL layer is in progress, but for a new major version and for so many users it will be at least 2 years before every user is upgraded, others might stay on the old version indefinitely, for whatever reason.

Because of the frequency the connection is used, marshalling from a SecureString won't help, since the immutable old copies stick in memory until GC comes around. Integrated Windows security isn't an option, since some clients don't work on domains, and other roam and connect over the net.

How can I secure the connection string, in memory, so it can't be viewed with windbg?

Answer 1

If you control a machine to the extent that you can read another process's memory, you can also replace the reference to the SecureString class with a reference to string. You'll have access to any private keys that the other process can use.

There is no defense against a hacker that owns your process memory. :)

Answer 2

Not a real answer to the question but still:

Try to use windows authentication instead of sql authentication. Even if you manage to secure password in the program memory user can see it by using traffic sniffer.

Another advantage of windows authentication is that sql server does not need to store password hashes of users. With sql authentication determined hacker can bruteforce password from hash or substitute it with another one. Actually the password can be replaced very easily with use of some programs.

Answer 3

Communication between a process and a Sql Server ideally happens on a backbone and if that is compromised then this is the least of your worries.

Answer 4

Since it's a client-side desktop application, if you are wondering that your connection string credentials might be exposed to some hackers, this is a design flaw...

If you connect to your sql server with admin credentials, this is your problem. You should create a user with restrictions and use it in your app.

If you are affraid to expose your database, you could access a webservice from the app. This webservice would then access the database and return the results.