Some parts of the framework that currently use SecureString
:
- WPF’s
System.Windows.Controls.PasswordBox
control keeps the password as a SecureString internally (exposed as a copy throughPasswordBox::SecurePassword
) - The
System.Diagnostics.ProcessStartInfo::Password
property is aSecureString
- The constructor for
X509Certificate2
takes aSecureString
for the password
The main purpose is to reduce the attack surface, rather than eliminate it. SecureStrings
are “pinned” in RAM so the Garbage Collector won’t move it around or make copies of it. It also makes sure the plain text won’t get written to the Swap file or in core dumps. The encryption is more like obfuscation and won’t stop a determined hacker, though, who would be able to find the symmetric key used to encrypt and decrypt it.
As others have said, the reason you have to create a SecureString
character-by-character is because of the first obvious flaw of doing otherwise: you presumably have the secret value as a plain string already, so what’s the point?
SecureString
s are the first step in solving a Chicken-and-Egg problem, so even though most current scenarios require converting them back into regular strings to make any use of them at all, their existence in the framework now means better support for them in the future – at least to a point where your program doesn’t have to be the weak link.