我正在寻找一种比密码加盐和散列更强大的方案。
我想要不会泄露的密码文件/数据库：
我的基本想法是对用户名和密码进行散列和加盐，并将 1000 个“陷阱”条目添加到数据库中（例如，以 _xxxx 结尾的随机用户名和以 _yyyy 结尾的随机密码，这不会'对真实用户无效）。
当然，当有人尝试登录时，我必须对照数据库中的所有行进行检查。
这个方案安全吗？
注意事项：
编辑：
我正在防止用户/密码文件（以及读取此文件的应用程序）泄露。如前所述，我需要保护用户的实际数量，以及他们的身份（或任何可能泄露他们身份的东西）。
【问题讨论】：
标签： database security encryption hash passwords
用户数量似乎是最难保护的数据点。您可以通过创建大量使用您所描述的加密名称的虚假用户来掩盖这一点。这些可以作为您描述的陷阱发挥双重作用，但是您需要能够将陷阱与真实用户区分开来，这意味着如果攻击者可以破坏陷阱检查器，他们就有可能这样做。
你试图保护它免受谁的攻击？
您想保护它免受破坏数据库的人的攻击，例如通过 SQL 注入或流氓系统管理员？
您想保护它免受破坏操作系统并获得对支持数据库表的文件的访问权限的人的攻击吗？
可以通过将对表的访问限制为经过充分审查的存储过程和严格的数据库访问控制来缓解前者。
可以通过将数据库文件放在加密分区上来缓解后者，但这会减慢访问速度和/或使启动复杂化。
【讨论】：
具有讽刺意味的是，用户数量越多，蛮力攻击者就越有可能偶然发现有效的组合 - 如果他们知道您有很多用户名/密码中包含 _xxxx 或 _yyyy 的用户，那可能给他们一个加密优势。
所以，我绝对建议你不要给你的假用户提供任何实际权限，这样即使是成功的猜测也不会产生对系统的权限。
其次，您可能需要考虑要防范的对象以及如何防范 - 人们普遍认为，良好的哈希/盐组合可以防范大多数可信的攻击；将用户名添加到该方案仅意味着您正在保护当前不存在的攻击。
另一方面，您没有采取任何措施来防范“便利贴上的用户名”、“密码 = 性别”等更为常见的攻击媒介。
改进“用户名/密码”的最常见方法是要求用户拥有一些实物。
【讨论】：