我最近问了一个问题“Is it a bad idea to bind PasswordBox password?”的要点是，尽管现在WPF应用程序倾向于遵循MVVM设计模式，但WPF PasswordBox似乎是故意设计的，以防止密码被绑定。然而，人们已经找到了绑定它们的方法，这意味着它们作为视图模型的一部分保存在内存中（更糟糕的是，如果密码只是从PasswordBox中检索并在现场检查，我猜）。
这种情况导致了一个更基本的问题。将密码存储在内存中的真正风险是什么？可能发生什么以及发生的可能性有多大？ （当我说 store 时，它意味着作为登录过程的一部分;之后它们永远不会被保存在内存中...除非他们无论如何都要驻留在内存中，直到垃圾收集器启动英寸）
有些人认为“如果攻击者可以读取你的记忆，你就会100％丢失。”（评论this question），这表明你是否将密码存储在内存中可能是多余的，因为如果他们有权访问你的内存，你就会被搞砸了（参见Troy Hunt's article on Heartbleed，其中显示了一个如何在一个无法覆盖的环境中访问内存的例子）。
另一方面，可以将密码保留在托管内存中 - this blog post显示了一个非常详细的示例，this MSDN article显示了与SecureStrings进行转换的方法。但是，我并不完全相信这是多么必要。首先，要做到这一点需要相当多的工作，并且遵循“如果他们能够读到你的记忆，你还是被搞砸了”的论点，它甚至可能都没用。其次，仅仅因为密码在非托管内存中，并不意味着它是安全的（参见上面的Heartbleed示例）;优点实际上是限制密码在内存中的时间量，以及之后将内存归零。
所以...总而言之，是否值得将密码从托管内存中删除？
答案 0 :(得分：2)
您似乎关注用户端的安全性。我认为我们同意，如果您的攻击者可以写您的进程内存，那么无论您采用何种聪明的技巧，您的安全性都会消失。如果您的攻击者既不能读取也不能写入您的进程内存，即使在内存中的密码方案中也是如此。
因此，问题集中在攻击者可以自由读取您的进程内存但无法操作的情况。无论你保存，加密或隐藏什么，你加载，解密或揭开的例程也在内存中。所以基本上，你可以用来保护数据的每种方法都不是硬安全性，而是默默无闻的安全性。迟早，它也将被阅读。然后它将用于破坏您的安全。
因此，只要您没有一些非常好的和怪异的硬件，如果有人能够读取您的过程，他就能够破坏您的安全性。可能需要一段时间，您的安全措施越好，需要的时间就越长。但它从来都不是设计的“安全”，只有在需要花费更多努力才能打破安全性时，它才是安全的。
作为一个没有事实支持的个人观点，我认为如果有人在您的Windows应用程序上获得了读取进程权限，那么您就会出于安全考虑。如果他获得了阅读流程权限，那么无论如何他已经根据你的方框进行了植入。
答案 1 :(得分：2)
我不同意＆＃34; 如果攻击者能够读取您的记忆，那么您将100％丢失＆＃34;。
这是鼓励人们在数据库中存储明文密码的态度。如果您问他们，他们可能会说，＆＃34; 如果攻击者可以读取您的数据库，则您100％丢失＆＃34;。
妥协密码比暴露系统内存或数据库要糟糕得多。因为密码使攻击者能够访问用户注册的其他系统，而不仅仅是暴露的系统。所以去任何极端以保护密码。没有理由不执行问题中引用的安全准则。如果出于任何原因（懒惰？）你无法实现它们，至少应尽早散列密码。