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
You can either use the new operator to make that directly. For example: SqlConnection conn = new SqlConnection( new SqlConnectionStringBuilder () { DataSource = "ServerName", InitialCatalog = "DatabaseName", UserID = "UserName", Password = "UserPassword" }. ConnectionString );
The best way to secure the database connection string is to encrypt the value within the configuration file. The application would then load the encrypted value from the config file, decrypt the value, and then use the decrypted value as the connection string to connect to the database.
The SqlConnection is opened and set as the Connection for the SqlCommand. The example then calls ExecuteNonQuery. To accomplish this, the ExecuteNonQuery is passed a connection string and a query string that is a Transact-SQL INSERT statement. The connection is closed automatically when the code exits the using block.
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 SqlConection object 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With