Forms Auth - 如何防止欺骗用户帐户只知道扩展的用户信息？答案

【问题标题】：Forms Auth - How to prevent dupe user account knowing only extended user information?Forms Auth - 如何防止欺骗用户帐户只知道扩展的用户信息？
【发布时间】：2009-02-02 17:07:08
【问题描述】：

我有点奇怪。请耐心等待我尝试解释它！

我正在使用表单身份验证并将其他用户信息存储在另一个表中（从 Forms Auth 引用的 UserID、加密的 SSN、Salt 值）。当用户注册到该站点时，我会询问 SSN、DOB 和 LName，并在他们创建帐户之前对我们的系统进行验证。我想确定该 SSN 在表单身份验证中是否有与之关联的帐户。由于 SSN 是使用盐值加密的，因此我无法在不查看每一行的情况下进行查找。

我只希望每个 SSN 有 1 个用户帐户。使用盐值会破坏这一点。

在我看来，解决这个问题的唯一方法是对 SSN 使用通用加密算法。当用户键入它时，我应用相同的加密算法并查看用户扩展属性表中是否存在值匹配。

这足够安全吗？

【问题讨论】：

我认为您将哈希与加密混淆。

标签： c# asp.net security forms-authentication

【解决方案1】：

不要使用相同的盐值，而是根据其他用户信息生成盐，以便可以重构。因此，一旦用户申请，您就可以重新生成盐，并且您可以生成预期的哈希并在单个查询中完成工作。

【讨论】：

您是说使用 FBA 账户信息中的盐吗？如果是这样，我不能使用它，因为我不知道它是哪个用户。为了解密 SSN，我需要 salt 值，但我不知道是哪个用户获取 salt 以创建 ssn 的加盐加密版本以进行比较。
重读主题，将加密的 SSN 及其密钥（尽管您称其为盐）存储在同一张表中似乎毫无意义。不过，我的建议是当用户输入 DoB 时和 LName，基于此生成盐。这将使您可以将盐应用于 SSN，以便您进行查找。

【解决方案2】：

如果您希望加密（而不是散列） SSN 值，那么将密钥存储在 Natso 指出的同一个表中并不是一个好习惯。这是充满危险的，因为密钥不会与它们保护的数据一起存储 - 如果攻击者设法获得您的数据库的转储，他将能够解密加密的内容，因为密钥是一起存储的。

应用程序应从安全密钥存储中获取密钥，然后可以使用该密钥对信息进行加密/解密。这样，您可以继续在数据库中存储敏感信息，从而保护您的信息，并应用不同的机制（通常是文件系统安全性）来保护您的密钥存储。

这当然是假设您的要求是以安全的方式将数据存储在数据库中，并在以后的某个时间点恢复这些数据。但是，如果您不希望数据通过算法后可恢复，您应该探索哈希的使用。

【讨论】：

【解决方案3】：

每次都使用相同的盐。然后你可以比较加密的值。

【讨论】：