When would I need a SecureString in .NET?

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 through PasswordBox::SecurePassword)
• The System.Diagnostics.ProcessStartInfo::Password property is a SecureString
• The constructor for X509Certificate2 takes a SecureString 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?

SecureStrings 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.