我正在寻找一种stornger方案，而不仅仅是密码加盐和哈希。
我想要不会妥协的密码文件/数据库：
- 用户数
- 用户名
- 用户密码
我的基本想法是对用户名和密码进行哈希和加盐，并将 1000 个"陷阱"条目添加到数据库中（例如，以 _xxxx 结尾的随机用户名和以 _yyyy 结尾的随机密码，这对真实用户无效）。
当然，当有人尝试登录时，我必须根据数据库中的所有行进行检查。
这个方案安全吗？
笔记：
- 用户是手动添加的。如果必须删除用户 - 登录名存储在保险箱中。 我
- 不确定我是否可以保护这个方案免受暴力方法的侵害，但我认为猜测名称和密码更难
编辑：
我正在防止用户/密码文件（以及读取此文件的应用程序）泄漏。如前所述，我需要保护实际的用户数量，以及他们的身份（或任何可能泄露其身份的内容）。
用户数量似乎是最难保护的数据点。 您可以通过创建大量虚假用户来掩盖这一点，这些用户使用您所描述的无意义名称加密。 这些可以作为您描述的陷阱承担双重职责，但是您需要能够将陷阱与真实用户区分开来，这意味着如果攻击者可以破坏陷阱检查器，他们可能会做同样的事情。
你想保护它的人是谁？
您是否想保护它免受破坏数据库的人的影响，例如通过SQL注入或流氓系统管理员？
您是否希望保护它免受破坏操作系统并获得对支持数据库表的文件的访问权限的人？
前者可以通过将对表的访问限制为经过充分审查的存储过程和严格的数据库访问控制来缓解。
后者可以通过将数据库文件放在加密分区上来缓解，尽管这可能会减慢访问速度和/或使启动复杂化。
具有讽刺意味的是，用户数量越多，暴力附加器就越有可能偶然发现有效的组合 - 如果他们知道您有很多用户的用户名/密码中带有_xxxx或_yyyy，这可能会给他们带来加密优势。
因此，我绝对建议您不要为您的虚假用户提供实际权限，因此即使是成功的猜测也不会产生对系统的权限。
其次，你可能要考虑你正在保护谁，以及如何 - 人们普遍认为，一个好的哈希/盐组合可以防止最可信的攻击;将用户名添加到该方案中只是意味着你正在防范目前不存在的攻击。
另一方面，您没有采取任何措施来防止"便利贴上的用户名"，"密码=性别"等更常见的攻击媒介。
改进"用户名/密码"的最常见方法是要求用户拥有物理内容。