将密码存储在内存中有多大的风险?

Gig*_*igi 5 c# security passwords wpf

我最近问了一个问题" 绑定PasswordBox密码是不是一个坏主意? "的要点是,虽然现在的WPF应用程序倾向于遵循MVVM设计模式,但WPF PasswordBox似乎是故意设计的,以防止密码被绑定.然而,人们已经找到了绑定它们的方法,这意味着它们作为视图模型的一部分保存在内存中(更糟糕的是,如果密码只是从PasswordBox中检索并在现场检查,我猜).

这种情况导致了一个更基本的问题.将密码存储在内存中的真正风险是什么?可能发生什么以及发生的可能性有多大?(当我说存储时,它意味着作为登录过程的一部分;之后它们永远不会被保存在内存中......除非它们在垃圾收集器启动之前始终驻留在内存中.)

有些人认为" 如果攻击者可以读取你的记忆,那么你就会100%丢失. "(对这个问题的评论),这表明你是否将密码存储在内存中可能是多余的,因为如果他们有你的话你就会被搞砸访问你的记忆(参见Troy Hunt关于Heartbleed的文章,该文章展示了如何在一个无法访问的环境中访问内存可能是非常灾难性的一个例子).

另一方面,可以将密码保存在托管内存之外 - 这篇博文显示了一个非常详细的示例,这篇MSDN文章展示了与SecureStrings进行转换的方法.但是,我并不完全相信这是多么必要.首先,要做到这一点需要相当多的工作,并且遵循"如果他们能够读到你的记忆,你还是被搞砸了"的论点,它甚至可能都没用.其次,仅仅因为密码在非托管内存中,并不意味着它是安全的(参见上面的Heartbleed示例); 优点实际上是限制密码在内存中的时间量,以及之后将内存归零.

所以...总之,是否值得将这些密码从托管内存中删除?

nvo*_*igt 4

您似乎担心用户方面的安全性。我认为我们同意,如果攻击者可以写入您的进程内存,那么无论您使用什么巧妙的技巧,您的安全性都会消失。如果攻击者既无法读取也无法写入您的进程内存,那么即使在内存中存在密码的情况下,您也是安全的。

因此,问题集中在攻击者可以自由读取进程内存但无法操纵它的情况。无论您保存、加密或隐藏什么,您加载、解密或揭示的例程也都在内存中。因此基本上,您可以用来保护数据的每种方法都不是硬安全性,而是隐性安全性。迟早,它也会被阅读。然后它将被用来破坏您的安全。

因此,只要您没有一些非常好的和怪异的硬件,如果有人能够读取您的进程,他就能够破坏您的安全性。这可能需要一段时间,您的安全措施越好,需要的时间就越长。但它在设计上从来都不是“安全”的,只有在破坏安全性所付出的努力超过其价值时,它才是安全的。

作为没有事实支持的个人观点,我认为如果有人获得了您的 Windows 应用程序的读取进程权限,那么您就失去了安全性。如果他获得了读取进程的权限,那么他无论如何都已经root了你的盒子。