The System.Data.SqlClient.SqlCredential class has a two argument constructor which accepts a username (System.String) and password (System.Security.SecureString).
After calling this constructor, is it safe to dispose the SecureString storing the password? I expect that the SqlCredential class should perform a one-way hash on the password according to the SQL server authentication scheme and not require continued access to the parameter... but perhaps this cannot be done until the connection is opened and a challenge is issued (a nonce may be involved in the HMAC calculation to prevent replay attacks). If SqlCredential does independently keep the needed information, then naturally I want to expedite erasure of the SecureString storage which is reversible.
I have been unable to find any statement in the documentation specifying whether the password SecureString object passed in must remain valid after the SqlCredential constructor returns.
SqlCredential doesn't actually process or store any password-derived data; it's just a convenience structure to hold the credential-related parameters associated with an SqlConnection.
The password SecureString instance needs to stay valid until the call to SqlConnection.Open() or that function will throw an ObjectDisposedException. If like mine, your application has any automatic reconnection logic, you'll need to keep the SecureString (or the ability to recreate it) indefinitely. At least on the .NET Framework with Win32, SecureString keeps its contents encrypted when at rest, so a process memory dump won't expose the secret.