I want to use a SecureString to hold a connection string for a database. But as soon as I set the SqlConnection object's ConnectionString property to the value of the securestring surely it will become visible to any other application that is able to read my application's memory?
I have made the following assumptions:
a) I am not able to instantiate a SqlConnection object outside of managed memory
b) any string within managed memory can be read by an application such as Hawkeye
Your absolutely right the SecureString does not provide you with any benefit when you need to pass the string to a managed API, such as setting a ConnectionString.
It's really designed for secure communication with secure non-managed APIs.
Microsoft could theoretically consider enhancing SqlConnection object to support a secure ConnectionString, but I think they're unlikely to do so because:
SecureString is really only useful in a client app, where e.g. a password is built character by character from user input, without ever having the whole password in a managed string.
In such an environment, it's more common to be using Windows authentication for connections to SQL Server.
On a server there are other ways to protect the SQL Server credentials, starting by limiting access to the server to authorized administrators.
2012
Microsoft did enhance the SqlConnection class to support a secure ConnectionString by passing a SqlCredential to the new SqlConnection.Credential property:
SecureString pwd = AzureVault.GetSecretStringSecure("ProcessPassword");
SqlCredential = new SqlCredential("Richard", pwd)
connection.Credential = cred;
Unfortunately no other DbConnection descendant (e.g., OdbcConnection, OleDbConnection, OracleConnection, EntityConnection, DB2Connection) supports it.
Yes you can and yes you should use SecureString to avoid letting password linger in the clear in memory and open up to attacks. Rather than using a sql connection string, you need to use the new SqlCredential class which Password property is a SecureString. Please refer to the below articles for help.
https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcredential.password(v=vs.110).aspx
http://www.codeproject.com/Tips/408901/Storing-your-connection-string-password-in-SecureS
Why is the connection string an issue? Wouldn't the password be what you want to protect (unless you're putting the password in the connection string which is optional for all drivers that I've seen). That being said, the password will usually have to be "in the clear" in memory at some point (unless the driver has some api that allows encrypted passwords or something, but that probably wouldn't actually help much anyway).
Usually this is not a problem because the process is in a secure environment, like on a web server, or running as a system admin type of account (so normal users cannot access the process memory), or usually both. If this is on a client's machine running in userland you must assume that the process is compromised anyway and this wouldn't help. Once you secure the process you don't have to worry about things like this.
Assigning a SecureString value to SQLConnection.ConnectionString will bypass the security, making it useless.
A SecureString is meant to fix these normal string issues, ref:
IMHO the SecureString type is a patch for a shoddy security implementation, and currently SecureString hasn't been implemented all across the framework, so it's benefits can't be used fully.
I have the same problem, I'm opting for RSA encryption storing sensitive info in memory.
Another solution is hosting your data access layer via a service on the database server, and the service runs under the local system account, that connects to the database and serves the data, while the local user wont have access to the service config.
If you are that concerned about security I suggest you should enable SSL in SQL server and communicate with it using SSL.
