我正在寻找一种存储方案，而不仅仅是密码腌制和散列。
我希望密码文件/ DB不会妥协：
我的基本想法是对用户名和密码进行散列和加盐，并将1000个“陷阱”条目添加到数据库中（例如，随机用户名以_xxxx结尾，随机密码以_yyyy结尾，赢得了' t对真实用户有效。）
当然，当有人试图登录时，我将不得不针对数据库中的所有行进行检查。
这个方案安全吗？
注意：
修改
我正在防止用户/密码文件（以及读取此文件的应用程序）泄漏。如上所述，我需要保护实际的用户数量，以及他们的身份（或任何可能泄露其身份的内容）。
答案 0 :(得分：3)
用户数量似乎是最难保护的数据点。您可以通过创建大量虚假用户来掩盖这一点，并在您描述时加密无意义的名称。这些可以作为您描述的陷阱发挥双重作用，但是您需要能够将陷阱与真实用户区分开来，这意味着如果攻击者可以破坏陷阱检查器，攻击者也可以这样做。
你是谁想要反对它？
您是否希望通过SQL注入或流氓系统管理员来保护它免受恶意攻击？
您是否想要保护它免受那些破坏操作系统的人并获得对数据库表后面文件的访问权限？
前者可以通过将对表格的访问权限限制在经过充分审查的存储过程以及严格的数据库访问控制来缓解。
后者可以通过将DB文件放在加密分区上来缓解，但这会降低访问速度和/或使启动变得复杂。
答案 1 :(得分：1)
具有讽刺意味的是，用户数越多，蛮力获取者就越有可能偶然发现有效组合 - 如果他们知道你的用户名/密码中有很多用户使用了_xxxx或_yyyy，那么给他们一个密码学的优势。
所以，我绝对建议你给虚假用户没有实际的特权，这样即使是成功的猜测也不会产生系统的权利。
其次，您可能想要考虑一下您正在保护谁，以及如何 - 一个好的哈希/盐组合可以防止大多数可信的攻击被广泛接受;将用户名添加到该方案只是意味着您可以防止当前不存在的攻击。</ p>
另一方面，你没有采取任何措施来防范更常见的“发布便笺上的用户名”，“密码=性别”等攻击媒介。
改进“用户名/密码”的最常用方法是要求用户拥有物理内容。