如何在没有 SecureString 的情况下保护字符串？

Question

用例是在c#的内存编程中保护字符串。 Microsoft 本身不鼓励使用 SecureString (https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.7.2) 类。

我想知道它是否可以有效替代：

• 将字符串转换成字节数组并立即将字符串设置为null（并最终调用垃圾收集器），
• 使用 ProtectedMemory 类加密字节数组。

有什么建议吗？

Answer 1

除了SecureString 类，别无选择。微软鼓励的“替代”是here：

处理凭据的一般方法是避免使用它们，而是依靠其他方式进行身份验证，例如证书或 Windows 身份验证。

因此，如果您确实需要凭据并且没有其他方法：在 .NET Framework 上，请使用 SecureString。对于 .NET Core，目前别无选择。

Answer 2

我不会说它“被微软劝阻”——这是一种过于简单化的说法。实际原因在此页面 (https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md) 中给出，并且论点似乎是“在 .NET Core 中使用它不值得”，而不是整体上不安全。

我认为SecureString 是安全的...但仅适用于 Windows 上的 .NET Framework。我链接到的页面来自跨平台的 .NET Core 项目 - 因此不鼓励或禁止在 .NET Core 中使用 SecureString 是有意义的 - 但如果您的项目针对 .NET Framework（这是专有的到 Windows）或者是针对 Windows 的 .NET Core for - 那么你很好。引用如下（强调我的）：

数组的内容是未加密的.NET Framework 除外。

顺便说一句，如果您只使用 Append 方法直接将机密直接读取到 SecureString 中，则可以安全地使用 SecureString 来避免内存中的明文。这在从控制台（伪代码）读取密码时最有用：

Console.WriteLine( "Enter your password" );
SecureString password = new SecureString();
while( Char c = Console.ReadKey() != '[Enter'] ) {
    password.Append( c );
}

...但是，如果您之后需要访问字符串的明文版本，那么它的安全性就会降低（尽管明文字符串有望被 GC 收集为第 0 代对象）。

关于您的建议：

• 将字符串转换为字节数组，并立即将字符串设置为null（并最终调用垃圾收集器）
• 使用 ProtectedMemory 类加密字节数组。

这正是 SecureString 的工作原理，它仍然存在同样的问题：加密内容的明文副本仍然在内存中存在很短的一段时间 - 这就是问题所在。

Answer 3

所以你要问的基本问题是“既然微软不鼓励使用 SecureString，我可以自己动手吗？”。

嗯，除了您的实现可能不如 Microsoft 的原始版本安全之外，它还会至少共享相同的问题，因为它们与特定的实现无关，而是与这个概念。

如果你想使用这个概念，你也可以使用 SecureString。解决方案是不要在内存中使用加密凭据的概念，无论是使用 Microsoft 的类还是使用您自己的自制软件。

Answer 4

tl;dr：SecureString 是个好主意。微软不再推荐的原因是 .NET Core 做不到，因为 Linux 不支持加密。

简答

• 使用字符数组
• 加密

长答案

您需要 SecureString 的原因有两个。

第一个类似于 HeartBleed 攻击，SecureZeroMemory 存在的原因，以及 Windows 在将内存页提供给您之前总是清零的原因：避免信息泄露。

额外阅读

终端服务将未加密的用户密码保存在 RAM 中。

• https://pentestlab.blog/2021/05/24/dumping-rdp-credentials/

第二个，也是 .NET 中存在 SecureString 的原因，是因为您无法调用 SecureZeroMemory。 .NET 中的字符串是不可变的，您无法控制它们的生命周期。

所以为了解决这个问题有两个要素：

1. 您可以切换到字符数组。

当它是一个数组时，这意味着你可以擦除内容。这意味着当您处理完敏感的信用卡号、比特币私钥、密码、英特尔蓝光主密钥后，您可以在道德上等同于 ZeroMemory：您可以擦除它们

这解决了完全无法擦除 C# 字符串的问题

1. 用CryptProtectData加密

另一个，不相关，SecureString 的优点是原始字符串不会出现在内存转储、虚拟机 RAM 快照、Web 服务器日志、调试器监视窗口中。或者在 HeartBleed 攻击的情况下，不会出现在分发给其他网站用户的未初始化数据中。

这是 SecureString 提供的两个核心元素。

两者都可以复制。 .NET Core 没有它们的原因并不是因为 SecureString 是一个坏主意、一个浪费的想法、一个不完整的想法，或者 “没有兑现它的承诺”。相反，这是因为 Linux 没有 CryptProtectData 的等价物。而且由于 .NET Core 必须是跨平台的，它们必须迎合最低的公分母。所以他们举起手说把它拿走。

但 SecureString 与以下概念一样有效：

• 零内存
• SecureZeroMemory
• Windows 在将一页 RAM 分配给您的进程之前将其清零
• 为什么当您设置文件有效数据时，Windows 会将文件内容归零

任何说其他话的人都是在撒谎。

提醒 - 您要使用 SecureString

您想使用 SecureString

• 出于同样的原因 SecureZeroMemory 存在
• 出于同样的原因RtlSecureZeroMemory 存在
• 出于同样的原因CryptProtectData 存在
• 出于同样的原因CryptProtectMemory 存在
• 出于同样的原因，Windows zero 在将内存页提供给您的进程之前会先将其取出
• 出于同样的原因 Windows zero's out file contents before giving it to your process
• 出于同样的原因，HeartBleed 必须被修复
• 同样的thing that Facebook got in trouble for
• 出于同样的原因iOS wipes your key from memory when the device locks
• 出于同样的原因VeraCrypt audit dinged them for not wiping keystrokes from memory
• 同样的原因you can encrypt your pagefile
• 同样的原因you can wipe your pagefile on shutdown
• LastPass、1Pass、KneePass、Windows Credential Manager 加密密码的原因相同

这是否意味着信用卡号在某个时候在内存中是明文形式的：

不，原因是它的用途非常有限，在大多数情况下，字符串要么保留在内存中，要么重新出现。原始字符串保留在内存中，直到它被 GCd。由于 SecureString 在 Win32 API（或 Linux）中没有对应物，因此一旦应用程序尝试对其执行任何操作，原始字符串就会重新出现。即使在 SDK 中，也只有 NetworkCredentials 正确使用了它，而且 SecureString 不是 Windows 概念，所以一旦你使用 Windows API，它就会被转换回来。

• 是的，信用卡号在某些时候以明文形式保存在内存中。
• 是的，用户的 bitlocker 密码曾在某个时间点在内存中。
• 是的，iOS 用户的 PIN 曾经在内存中。
• 是的，BitCoin 私钥在某个时间点在内存中。
• 是的，加密页面文件中的数据在某个时间点在 RAM 中未加密。

但我们必须意识到的是：

• 这并不意味着您不应该从内存中清除它
• 这并不意味着您不应该阻止它出现在日志文件中
• 这并不意味着您不应该阻止它出现在交换文件中
• 这并不意味着您不应该阻止它出现在故障转储文件中
• 这并不意味着您不应该阻止它出现在监视窗口中
• 这并不意味着您不应该阻止它出现在快照中

这些是很好的纵深防御措施。

而且任何人说不同都是完全错误的。