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 its 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 uninheritable, 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?
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. 🙂