Microsoft 是否有推荐的方法来处理 HttpClient 中标头中的机密？

Question

非常密切相关：如何在没有 SecureString 的情况下保护字符串？

也密切相关：我什么时候需要 .NET 中的 SecureString？

极其密切相关（OP 正在尝试实现非常相似的东西）：C# & WPF - Using SecureString for a client-side HTTP API password

.NET Framework 有一个名为SecureString 的类。但是，即使是 Microsoft 也不再建议将其用于新的开发。根据第一个链接的问答，至少有一个原因是该字符串无论如何都会以明文形式存在于内存中至少一段时间（即使时间很短）。至少有一个答案还扩展了一个论点，即如果他们无论如何都可以访问服务器的内存，那么实际上安全性无论如何都可能会被击中，所以它不会帮助你。（第二个链接的问答暗示甚至讨论过将其从 .NET Core 中完全删除）。

话虽如此，微软的文档SecureString不建议更换，并且关于链接问答的共识似乎是这种措施无论如何都不会那么有用。

我的应用程序是一个 ASP.NET Core 应用程序，它广泛使用了对使用HttpClient该类的外部供应商的 API 调用。在通常推荐的最佳做法的HttpClient是使用单个实例，而不是每个调用创建一个新的实例。

但是，我们的供应商要求所有 API 调用都包含我们的 API 密钥作为具有特定名称的标头。我目前安全地存储密钥，在 中检索它Startup.cs，并将其添加到我们HttpClient实例的标头中。

不幸的是，这意味着我的 API 密钥将在应用程序的整个生命周期中以明文形式保存在内存中。我发现这对于服务器上的 Web 应用程序来说尤其令人不安；尽管服务器由企业 IT 维护，但我一直被教导将企业网络视为半敌对环境，在这种情况下，不要纯粹依赖企业防火墙来确保应用程序安全。

对于此类情况，Microsoft 是否有推荐的最佳实践？这是他们反对使用的建议的潜在例外SecureString吗？（具体如何工作是一个单独的问题）。或者其他问答中的答案是否真的正确说我不应该担心像这样存在于内存中的明文字符串？

注意：根据对这个问题的回答，我可能会发布一个关于是否可以将类似的内容SecureString用作HttpClient标题的一部分的后续问题。或者我是否必须做一些棘手的事情，例如在使用之前填充标题，然后立即将其从内存中删除？（虽然这会给并发调用带来绝对的噩梦）。如果人们认为我应该做这样的事情，我很乐意为此创建一个新问题。

Answer 1

你太偏执了。

首先，如果黑客获得了对您的 Web 服务器的 root 访问权限，那么您面临的问题比被盗的超级机密 Web 应用程序凭据要大得多。方式，方式，方式更大的问题。一旦黑客站在密闭舱口的一侧，游戏就结束了。

其次，一旦你的信息安全团队检测到入侵（如果他们没有，同样，你有更大的问题）他们会告诉你，你要做的第一件事就是更改你的每个密钥和密码了解。

第三，如果黑客确实获得了对您的网络服务器的 root 访问权限，他们的第一个想法不会是“让我们进行内存转储以供以后分析”。转储文件相当大（通过网络传输需要时间，并且很可能会注意到网络流量）并且（至少在 Windows 上）挂起进程直到它完成（所以你会注意到你的网络应用程序没有响应） -两者都可能引发一些危险信号。

不，黑客可以在最短的时间内获取尽可能多的有价值的信息，因为他们知道他们的访问可能随时被发现。因此，他们将首先寻找唾手可得的成果——用户名和密码。然后他们将继续尝试找出连接到该服务器的内容，并且由于您的数据库凭据可能在该服务器的配置文件中，他们几乎肯定会将注意力转移到更有趣的目标上。

因此，考虑到所有因素，您的 API 密钥不太可能被泄露——即使是这样，也不会是因为您做了或没有做的事情。与试图保护已经（或应该）非常安全的东西相比，有更多的方法可以集中你的时间。而且，在一天结束时，无论您设置了多少安全层……API 或 SSL 密钥在某个阶段将是原始的，在内存中。