我想这是因为字符串是安全的，也就是说，黑客不应该能够读取它。如果用字符串初始化，黑客就可以读取原始字符串。

我相信之所以必须使用字符追加而不是一个平面实例化，是因为在后台向 SecureString 的构造函数传递“ password”时，会将“ password”字符串放在内存中，从而破坏了安全字符串的作用。

通过附加，您只是把一个字符在一个时间到内存中，这是可能不相邻的其他物理使它更难以重建原始字符串。我可能是错的，但是他们是这么跟我解释的。

该类的用途是防止通过内存转储或类似工具公开安全数据。

微软发现，在某些情况下，导致服务器(桌面，无论什么)崩溃，有时执行期函式库会做一个内存转储，暴露内存中的内容。SecureString 在内存中对其进行加密，以防止攻击者能够检索字符串的内容。

正如描述中所说的，这个值是加密存储的，这意味着进程的内存转储不会显示字符串的值(如果没有一些相当严肃的工作)。

之所以不能从常量字符串构造 SecureString，是因为这样 会在内存中就有了字符串的未加密版本。限制您分段创建字符串可以降低整个字符串同时存储在内存中的风险。

SecureString 的一个最大好处是，它可以避免由于页面缓存而将数据存储到磁盘的可能性。如果您在内存中有一个密码，然后加载一个大型程序或数据集，您的密码可能会被写入交换文件，因为您的程序在内存中被分页。使用 SecureString，至少数据不会以明文形式无限期地保存在磁盘上。

在框架的当前版本中，可以合理使用 SecureString 的场景非常少。它实际上只有在与非托管 API 交互时才有用——您可以使用 Marshall 对其进行封送处理。SecureStringToGlobalAllocUnicode.

一旦您将它转换为/从 System.String，您就失去了它的作用。

MSDN样本从控制台输入一次生成一个字符，并将安全字符串传递给非托管 API。这是相当复杂和不现实的。

您可能期望. NET 的未来版本对 SecureString 有更多的支持，这将使它更加有用，例如:

• 或类似于将控制台输入读入到 SecureString 中，而不需要示例中的所有复杂代码。

• 将其 TextBox.Text 属性存储为安全字符串的 WinFormsTextBox 替换，以便可以安全地输入密码。

• 对安全相关 API 的扩展，以允许将密码作为 SecureString 传递。

如果没有以上内容，SecureString 的价值将是有限的。

目前使用 SecureString的框架的一些部分:

• WPF 的 System.Windows.Controls.PasswordBox控件在内部将密码保存为 SecureString (通过 PasswordBox::SecurePassword作为副本公开)
• System.Diagnostics.ProcessStartInfo::Password属性是 SecureString
• X509Certificate2的构造函数采用 SecureString作为密码

主要目的是减少攻击面，而不是消除它。SecureStrings被“固定”在 RAM 中，所以垃圾收集器不会移动它或复制它。它还确保不会将纯文本写入到交换文件或核心转储中。这种加密更像是一种混淆，不会阻止一个坚定的黑客，尽管他能够找到用来加密和解密它的 对称密钥。

正如其他人所说的，必须逐个字符创建 SecureString的原因是因为其他方法的第一个明显缺陷: 您可能已经将秘密值作为普通字符串创建了，那么重点是什么呢？

SecureString s 是解决“鸡和蛋”问题的第一步，所以尽管目前大多数情况下需要将它们转换回常规字符串才能使用它们，但它们在框架中的存在意味着将来对它们的更好支持——至少在某种程度上，你的程序不必成为薄弱环节。

编辑 : < em > 不要使用 SecureString

现在的指导说这个课程不应该被使用。详细信息可以在这个链接找到: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md

摘自文章:

DE0001: 不应该使用 SecureString

动机

• SecureString的目的是避免在过程中存储秘密 以纯文本形式存储。
• 然而，即使在 Windows 上，SecureString也不是作为一个操作系统概念存在的。
  • 它只是使得得到纯文本的窗口更短; 它不完全 因为.NET 仍然必须将字符串转换为纯文本 代表。
  • 这样做的好处是，纯文本表示不会被闲置 作为 System.String的实例——本机缓冲区的生存期为 更短。
• 除了.NETFramework 之外，数组的内容是未加密的。
  • 在.NETFramework 中，内部字符数组的内容是加密的。 NET 也不支持所有环境中的加密 由于缺少 API 或关键的管理问题。

建议

不要对新代码使用 SecureString 数组的内容在内存中没有加密。

处理凭据的一般方法是避免使用凭据 依赖其他方法进行身份验证，如证书或 Windows 认证。

编辑: 原始摘要如下

很多很棒的答案; 这里是已经讨论过的内容的一个快速概要。

微软已经实现了 SecureString 类，努力为敏感信息(如信用卡、密码等)提供更好的安全性。它自动提供:

• 加密(在内存转储的情况下) 或页缓存)
• 固定在记忆中
• 能够标记为只读(以防止任何进一步的修改)
• 不允许传入常量字符串的安全构造

目前，SecureString 的使用受到限制，但预计将来会得到更好的采用。

根据这些信息，SecureString 的构造函数不应该只是获取一个字符串并将其分割为字符数组，因为拼写出字符串会破坏 SecureString 的用途。

附加信息:

• 来自.NET 安全性的 邮寄 博客上谈论的内容与 盖在这里。
• 还有一个是“ nofollow noReferrer” 重新审视它，并提到一个工具 可以转储的内容 SecureString.

编辑: 我发现很难选择最好的答案，因为有很多好的信息，太糟糕了，没有辅助的答案选项。

我会停止使用 SecureString。看来少年组的人不支持了。甚至可能在未来拉它-https://github.com/dotnet/apireviews/tree/master/2015-07-14-securestring。

中的所有平台删除 SecureString 中的加密。NET 核心-我们应该过时的 SecureString-我们可能不应该在。NET 核心

简短的回答

为什么我就不能说:

SecureString password = new SecureString("password");

因为现在内存中有了 password，没有办法擦除它——这正是 SecureString的意义所在。

长答案

SecureString之所以存在，是因为在处理完敏感数据后，无法使用 零记忆来擦除它。它的存在是为了解决存在 CLR 的 因为的问题。

在一个常规的 本地人应用程序中，你可以调用 SecureZeroMemory:

用零填充内存块。

注意: SecureZeroMemory 和 ZeroMemory是一样的，除了编译器不会优化之外。

//Wipe out the password
for (int i=0; i<password.Length; i++)
password[i] = \0;

String connectionString = secureConnectionString.ToString()

SqlCredential cred = new SqlCredential(userid, password); //password is SecureString
SqlConnection conn = new SqlConnection(connectionString);
conn.Credential = cred;
conn.Open();

SqlConnection.ChangePassword(connectionString, cred, newPassword);

private static string CreateString(SecureString secureString)
{
IntPtr intPtr = IntPtr.Zero;
if (secureString == null || secureString.Length == 0)
{
return string.Empty;
}
string result;
try
{
intPtr = Marshal.SecureStringToBSTR(secureString);
result = Marshal.PtrToStringBSTR(intPtr);
}
finally
{
if (intPtr != IntPtr.Zero)
{
Marshal.ZeroFreeBSTR(intPtr);
}
}
return result;
}

for (int i=0; i < PasswordArray.Length; i++)
{
password.AppendChar(PasswordArray[i]);
PasswordArray[i] = (Char)0;
}