SecureString goes some way to secure the in memory instance of a string, however you should be aware of some significant drawbacks.
- A SecureString (just as svick points out) can be retrieved without a decryption key, so any hacker skilled enough to retrieve this chunk of memory you can safely assume can easily perform this minor operation to retrieve the plain text string. Consider the simplicity of
SecureStringToBSTR(input);
SecureString needs to be populated in a character by character way as there is no .Text property Get or Set accessor to use. On blogs including MSDN you will often see code like the following:
public static SecureString StringToSecureString(string input)
{
SecureString output = new SecureString();
int l = input.Length;
char[] s = input.ToCharArray(0, l);
foreach (char c in s)
{
output.AppendChar(c);
}
return output;
}
The significant issue with this code is that the developer allowed the input
string to ever exist in memory in the first place. The User Control or WinForm TextBox of PasswordBox used to collect this password from the user should never collect the whole password in one operation, as
- Hackers can access memory directly and retrieve the password directly from the control on the stack or inject code to retrieve the password on the instantiation of this method
- If your last Memory Dump still resides on your machine from your last blue-screen, and this control was populated with your plain text password, then the password is sitting in a tidy little file ready for your Hacker to pick up and use at his/her leisure.
Instead consider options where the KeyPress is used to retrieve each character from the user, otherwise, WPF's PasswordBox is backed by a SecureString by default I believe (someone else may confirm this).
Finally there are much more simple ways to collect passwords from users like Key Loggers. My recommendation is to consider your user demographic, exposure risk, and determine whether something as trivial as a SecureString is really going to cut it.