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?