我正在为网站开展用户身份验证工作。
阅读了Innocent Code一书后，我遵循了将密码存储为哈希（用户名+密码+盐）的建议。单独散列密码的理论是不安全的（受字典/彩虹表攻击，如果多个用户使用相同的密码，则可能不是任何给定站点上的唯一散列）。将用户名和密码一起散列在任何给定的站点上应该是唯一的，但是用户可以在不同的站点上重复这些相同的凭据，因此如果它在一个站点上被破解，它可能会在许多站点上被破解。因此，使用用户名，密码和特定于站点的盐值的哈希应该使全局唯一的哈希值（受哈希算法本身的限制）
我目前在数据库中有两个表：用户和密码。
users表存储用户名和有关该用户的相关信息（权限，首选项等），但不包含密码。
密码表是存储密码哈希的单列表，如上所述。哈希是它在该表上的主键。我已经假设散列应该是足够独特的，我不可能最终得到重复的散列，因此重复键（如果我在这个假设中错了，请纠正我。）通过重新创建散列来完成身份验证从用户提供的用户名和密码（加上秘密盐）并检查数据库中是否存在该哈希值。如果它在那里，他们会进行身份验证。
到目前为止，这很好用。
使用此方案，应该无法将密码哈希与任何特定用户相关联。知道用户ID不会帮助任何人找到相应的密码哈希值。
我不确定我是如何想出这个方案的。我以为我会在无辜的代码书中读到它，但我只是再次读它，它只能用盐来扫描密码。它似乎没有建议将密码从用户表中分离出来。
现在我的问题是，如果我必须从系统中删除用户，我无法知道哪个密码与该帐户相关联，因此我无法删除任何密码。我可以看到将来在密码表中以孤立密码哈希结束。
所以我的问题是：我该怎么处理这个？
通过将密码与用户表分开，我是偏执狂吗？为自己创造一个比我解决的更大的问题？将散列密码放在用户表中真的会受伤吗？有一个表处理所有用户信息会更好吗？
答案 0 :(得分：4)
是的，我认为你是偏执狂，造成比你正在解决的更大的问题，你应该把哈希密码放在用户表中。
如果某人专注于破解您的用户名+密码+盐，那么他们更有可能只是在您的托管设施，员工或其他方面贿赂某人。如果你不是VISA，这种安全级别可能有点过分。
答案 1 :(得分：2)
我认为将密码放在users表中是不会有问题的，因为你已经以一种非常非常难以发现原始状态的方式对它们进行了哈希处理。
另请注意，您为保护密码所付出的工作量应与您在网站上的其他安全措施保持一致。例如，如果用户通过非SSL连接发送密码，将密码放在他们自己的表等中是没有意义的，因为破解者可能只是通过收听密码来发现用户的密码。连接。
答案 2 :(得分：2)
将散列密码存储到用户应该是安全的（您也可以为每个用户提供随机盐，因此每个密码不使用相同的盐）。如果黑客获取了您的数据库，如果密码是经过哈希处理的，那么它是否与特定用户相关并不重要（如果您真的对它有偏执，那么您也可以始终对用户名进行哈希）。
答案 3 :(得分：2)
我们假设您的方案合理。如果您孤立密码哈希，并且您的盐永远不会更改，那么您必须禁止将来使用曾经活跃的用户名以防止以前的用户进入他们的同名帐户。无论你怎么样，这都不可能让你成为朋友。 （至少不是我;我不喜欢那些不会让我重新注册自己名字的网站，如果很久以前我有一个帐户。我不喜欢更多让其他人进入我帐户的网站......）
可能没有“正确”的答案，但考虑使用变量作为盐的一部分。例如，如果salt是用户帐户创建时间戳的哈希值，那么本身是否可以从该时间戳计算出一个值？有人必须弄清楚你的哈希密码方案和哈希时间戳方案，以及在用户名与密码哈希之间的关联可能会危及任何事情之前生成时间戳哈希盐的方案。
然后，您可以更安全地在用户表中存储密码+哈希变量 - 盐渍时间戳值。
答案 4 :(得分：0)
数据库是私有的（没有公共访问权限）？
您确定没有任何SQL注入潜在问题吗？
您的salt和hash密钥是否受到保护？
具有允许访问数据库表和密码哈希的安全漏洞会产生什么影响？ （此时，其余数据将是我最关心的问题......）
我认为在单独的表中使用密码哈希是不值得的。