Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Some parts of the framework that currently use <code>SecureString</code>:</p> <ul> <li>WPF's <code>System.Windows.Controls.PasswordBox</code> control keeps the password as a SecureString internally (exposed as a copy through <code>PasswordBox::SecurePassword</code>)</li> <li>The <code>System.Diagnostics.ProcessStartInfo::Password</code> property is a <code>SecureString</code></li> <li>The constructor for <code>X509Certificate2</code> takes a <code>SecureString</code> for the password</li> </ul> <p>The main purpose is to reduce the attack surface, rather than eliminate it. <code>SecureStrings</code> are "pinned" in RAM so the Garbage Collector won't move it around or make copies of it. It also makes sure the plaintext 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.</p> <p>As others have said, the reason you have to create a <code>SecureString</code> 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? </p> <p><code>SecureString</code>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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload