如何在 Silverlight 中加密用户的密码？答案

【问题标题】：How can I encrypt a user's password in Silverlight?如何在 Silverlight 中加密用户的密码？
【发布时间】：2010-02-19 15:34:21
【问题描述】：

我有一个 Silverlight 3 应用程序，它连接到服务器以执行各种操作。我的用户使用表单身份验证登录，但他们请求的操作是使用 AppPool 帐户在服务器上运行的，因此当他们进入审核日志时，他们会根据 AppPool 帐户进行记录。 PCI DSS 法规现在要求用户自己的 ID 存在于审计日志中，这意味着必须使用用户的信用来采取行动。现在，我可以在用户登录并提交每个请求时保存用户的凭据，并且服务器正在执行的操作可以使用这些凭据。但是 PCI 法规说，如果保存凭据，则必须对其进行加密（以避免有人窃取 PC 的内存转储并获取密码）。

我能看到的唯一方法是从服务器获取公钥并用它加密密码，然后提交加密密码并使用私钥在服务器上解密。但 Silverlight 没有非对称加密。

我想我离问题太近了，必须有另一个解决方案，但我看不出它是什么。有人可以帮忙吗？

澄清

这是一个内部应用程序。到目前为止，我一直在使用 IIS Forms AuthN over SSL 到 Active Directory - 我不担心在传输过程中保护密码，只是当它保存在客户端的内存中时。据我了解，因为我使用的是Forms Authentication，所以除非我使用LogonUser，否则无法在服务器上进行模拟，这意味着我需要服务器上的密码，所以我每次都需要传输它，所以我需要持有它在客户端，在内存中，直到应用关闭。

【问题讨论】：

请澄清“信用”。我不认为 PCI regs 要求对用户 ID 进行加密，所以我在这里看不出有什么问题。不要保存密码，只需将用户 ID 保存在当前会话中并将其用于日志记录。
我觉得你很困惑。我根本看不到公钥密码学如何帮助这种情况。为什么不能通过 ssl 使用普通的用户名/密码登录系统，然后将密码存储为 sha256 哈希。
我已经澄清了我原来的帖子 - 我希望能解释我的担忧所在。

标签： security silverlight-3.0 passwords encryption-asymmetric

【解决方案1】：

您是说您需要存储密码以便在 silverlight 应用程序中重复使用吗？如果您担心密码出现在未加密的内存中，那么 Silverlight 那么我认为您遇到了麻烦。

.NET 框架确实有一个 SecureString 类，用于您概述的确切用途。

不幸的是，Silverlight 版本的框架没有这个类。因此，即使您要在某些时候对密码的逻辑存储进行加密，您的代码也需要在使用之前对其进行解密。此时分配的内存包含未加密形式的字符串。

我对表单身份验证了解不多，但如果您可以将用户原则映射到域用户（您似乎表明您需要），那么您将希望在服务器上运行代码时使用模拟。

或者停止使用表单身份验证并使用 Windows 集成身份验证，您绝对可以使用模拟服务器端。

【讨论】：

消息摘要是存储密码的唯一正确方法。通过使用块密码或流密码存储密码，您违反了 CWE-257 cwe.mitre.org/data/definitions/257.html。在没有深入了解利用过程的情况下，请停止向人们提供不安全的安全建议。
@Michael：你有权在你认为合适的时候给出你的建议，并评论甚至否决我的建议。但是请不要告诉我我应该做什么。安全似乎确实让人们失去了狂热，但安全是一个非常相对的事情。从一个角度来看，足够好的安全性在另一个角度是完全不可接受的。我没有建议 OP 存储字符串的加密版本，我已经指出我认为它不能在 Silverlight 中完成，并就如何避免该要求给出了建议。
@Anthony 安全问题在于它“有效”，直到你被黑客入侵，并且 OP 无法区分。您提出的是根据 NIST 的漏洞，如果将其付诸实践，可能会发布 CVE 编号。这是非常黑白的。我恭敬地请您停止回答与安全性，尤其是密码学有关的问题。我推荐阅读“盗版密码学”。
@Anthony 看到有人提出合法的安全问题并收到不正确的安全建议，结果人们被黑客入侵，这让我很困扰。安全是非常困难的，我一生的大部分时间都在这个领域工作。我正在尝试清理堆栈溢出，这让我成为了狂热者，对不起。
@Michael：热情是值得称道的，但你的方法不是。你无法保持理性正在破坏你的事业。您反复攻击“我的方法”，这实际上不是“我的方法”，而是 OP。我的方法如我的回答中所述是让现有的身份验证机制完成工作。顺便说一句，当 Windows 在 Intranet 上的 NTLM 质询/响应期间自动发送 Windows 凭据时，它如何处理这个问题？由于用户当时没有输入密码，它从哪里获取密码以完成响应？

【解决方案2】：

永远不要对密码使用加密。当您加密某些东西时，它会随之而来，应该有一种方法可以解密它。一种方式的哈希应该始终用于密码。 md5 和 sha1 已被证明对于任何安全系统来说都太弱了。应该使用 Sha256，在 silverlight 中这个库会处理它： http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256%28VS.95%29.aspx

事实上，使用“加密”存储密码已被漏洞家族CWE-257 识别。使用消息摘要是安全存储密码的唯一方法。这不是我编造的，它来自 NIST。存储密码时还会出现许多其他漏洞。这是 NIST 整理的THE LIST：

【讨论】：

这在晶体管身份验证过程中很好，但在需要存储密码时没有用，在某些时候需要密码的可解密版本。
@anthony 你再错误不过了。始终比较 2 个消息摘要。解密的可能性为众多攻击媒介打开了大门。
@anthony，实际上使用散列进行临时身份验证可能很糟糕，因为您可以重放散列而不必破坏它。使用滚动盐可以防止重放攻击。
@Michael：我不记得在这里提到过任何与哈希相关的内容。您是正确的，在哈希中使用一些额外的内容可以防止回复攻击，但我不确定这是否相关。 “2 条消息摘要”你在说什么？您是在建议可以将一些“摘要”事物从一个请求保留到另一个请求并以某种方式重新使用？这个“消息摘要”是什么？它如何帮助 OP 重新使用以前输入的凭据？
@anthony 我们在这里离开话题。 “临时身份验证”最好使用 SSL/TLS 完成。消息摘要函数是存储密码的最佳选择，并且生成的哈希不应泄露给攻击者。