为什么我可以在 Snoop 中看到 PasswordBox 的密码？答案

【问题标题】：Why can I see the password of a PasswordBox in Snoop?为什么我可以在 Snoop 中看到 PasswordBox 的密码？
【发布时间】：2018-03-13 17:37:24
【问题描述】：

我试图了解 PasswordBox 如何保护从外部应用程序读取密码。我不明白的是我怎么有能力用 Snoop 读取我的 WPF 窗口的密码：

我认为这就是 PasswordBox 应该解决的违规行为。

【问题讨论】：

AFAIK，这是一般行为。您不必担心
嗯，您或多或少不需要担心。密码以SecureString 的形式存储在内存中，在安全性方面不是一大步，但总比没有好（至少在不再需要时不会留在内存中）。为简单起见（因为许多/大多数 API 需要 string），当您阅读 Password 属性时，您会使用该密码创建一个 String。现在，该字符串受到正常 GC 的影响，并且内存内容不会被清理，那么它可能是可用的。如果您担心安全问题，请不要使用Password 属性
并改用SecurePassword（它返回密码的副本为SecureString，在未进行GC时将归零）。
非常感谢你们。我仍在探索所有这些是如何协同工作的。
显然，具有所需权限的应用程序可以访问您的应用程序并读取其内容（您无法真正停止），它甚至可以安装键盘挂钩来记录所有击键...

标签： c# wpf passwordbox

【解决方案1】：

为了在某一时刻可用，密码必须在内存中作为明文字符串和/或必须作为明文字符串可检索。 SecureString 和 PasswordBox 限制了漏洞的时间。但他们无法摆脱它。它可以做一些事情，比如通过 GC 强制积极收集，防止像 String itnerning 这样的优化，甚至在内存超出范围时用随机数据覆盖内存。

Passwrod 属性是您检索所述裸字符串的方式。 snoop 显然可以像您的代码一样查询它。

我个人认为，如果攻击者可以读取您的记忆，那么您几乎已经输掉了安全战。如果您在内存中获得了加密值，那么您可能也拥有那里的密钥。连同实际在两者上工作的代码。所以它不像攻击者不能像你一样解密它。这个任务有点复杂，但就是这样。

内存读取的漏洞是为什么Heartbleed 如此巨大的原因。您必须盲目相信 RAM。因为如果它受到损害，您将无能为力。

【讨论】：

“我个人认为，如果攻击者能够读取你的记忆，那么你几乎已经输掉了安全战。”不幸的是，我们的担忧来自合作者之间的项目内部。但是谢谢，这就是我想要理解的。
@MohammedLarabi 如果您不能信任自己的代码，那么事情就会复杂得多。您可以在具有较低权限（= 安全权限的子集）的单独沙盒化 AppDomain 中运行这些“低信任”插件。如果您想要更高程度的分离，那么您必须将您的应用程序拆分为单独运行的单独组件（我正在考虑 Docker，只是提到我想到的第一个解决方案，但它们也可能是使用低权限 Windows 用户运行的单独进程）。
哦，好吧...当然要为此付出代价。它可能是部署复杂性（因为 Docker 和/或 Windows 用户）以及在每种情况下的性能，因为调用和数据传输需要跨越进程边界，即使在最好的情况下（共享内存，如果适用）你仍然有一些开销。