如何保护用户名、密码和用户数量
我正在寻找一种比密码加盐和散列更强大的方案。
我希望密码文件/数据库不会受到损害：
- 用户数量
- 用户名
- 用户密码
我的基本想法是对用户名和密码进行哈希和加盐，并将 1000 个“陷阱”条目添加到数据库中（例如，以 _xxxx 结尾的随机用户名和以 _yyyy 结尾的随机密码，这对真实用户无效）。
当然，当有人尝试登录时，我必须根据数据库中的所有行进行检查。
这个方案安全吗？
注意：
- 用户是手动添加的。如果必须删除用户 - 登录名将存储在保险箱中。
- 我不确定是否可以保护此方案免受暴力方法的影响，但我认为猜测名称和密码更难
编辑：
我正在防止用户/密码文件的泄漏（以及读取该文件的应用程序）。如前所述，我需要保护用户的实际数量以及他们的身份（或任何可能泄露其身份的内容）。
I'm looking for a stornger scheme than just password salting-and-hashing.
I want passwords file/DB that will not compromise:
- Number of users
- User names
- User passwords
My basic idea is to hash and salt both the usernames and the passwords, and also to add 1000's of 'trap' entries into the database (for example, random user names ending with _xxxx with random passwords ending with _yyyy which won't be valid for real users).
Of course, when someone tries to log in, I'll have to check it against all lines in the database.
Is this scheme secure?
Notes:
- The users are added manually. If a user has to be removed - the login names are stored in a safe.
- I'm not sure if I can protect this scheme againt brute-force methods, but I think guessing both name and password is harder
Edit:
I'm protecting against a leak of the user/password file (as well as the application that read this file). As said, I need to protect the actual number of users, as well as their identities (or anything that may disclose their identities).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
用户数量似乎是最难保护的数据点。您可以通过创建大量虚假用户来掩盖这一点，这些用户的名称是按照您所描述的方式进行加密的。这些可以作为您描述的陷阱发挥双重作用，但是您需要能够将陷阱与真实用户区分开来，这意味着如果攻击者能够破坏陷阱检查器，他们就有可能做同样的事情。
你想保护谁？
您是否想保护它免受诸如 SQL 注入或流氓系统管理员等损害数据库的人的侵害？
您是否想确保其安全，防止有人危害操作系统并获取支持数据库表的文件的访问权限？
前者可以通过将对表的访问限制为经过严格审查的存储过程和严格的数据库访问控制来缓解。
可以通过将数据库文件放在加密分区上来缓解后者，但这可能会减慢访问速度和/或使启动复杂化。
Number of users seems to be the hardest datapoint to protect. You can mask this by creating large numbers of fake users with nonsense names encrypted as you describe. These can serve double duty as the traps you describe, but then you need to be able to distinguish a trap from a real user which means it is possible for an attacker to do the same if they can compromise the trap-checker.
Who are you trying to secure it against?
Do you want to secure it against someone who compromises the DB, e.g by SQL injection, or a rogue sysadmin?
Do you want to secure it against someone who compromises the OS and gains access to the files that back the database tables?
The former can be mitigated by restricting access to the table to well-reviewed stored procedures, and tough DB access controls.
The latter can be mitigated by putting DB files on an encrypted partition, though this can slow down access and/or complicate startup.
具有讽刺意味的是，用户数量越多，暴力攻击者就越有可能偶然发现有效的组合 - 如果他们知道您有很多用户的用户名/密码中包含 _xxxx 或 _yyyy，这可能会给他们带来密码学优势。
因此，我绝对建议您不要给虚假用户任何实际的权限，这样即使成功的猜测也不会产生对系统的任何权限。
其次，您可能需要考虑您要防范的对象是谁，以及如何防范——人们普遍认为，良好的哈希/盐组合可以防范大多数可信的攻击；将用户名添加到该方案仅意味着您正在防范当前不存在的攻击。
另一方面，您没有采取任何措施来防范“便利贴上的用户名”、“密码=性别”等更常见的攻击向量。
改进“用户名/密码”的最常见方法是要求用户有实体的东西。
Ironically, the larger the number of users, the more likely a brute force attacer is to stumble on a valid combination - and if they know that you have a lot of users with _xxxx or _yyyy in their usernames/passwords, that may give them a cryptographical advantage.
So, I would absolutely recommend that you give your bogus users no actual privileges, so that even a succesful guess yields no rights to the system.
Secondly, you might want to think about who you're protecting against, and how - it's widely accepted that a good hash/salt combination protects against most credible attacks; adding the username to that scheme just means you're protecting against attacks that don't currently exist.
On the other hand, you're doing nothing to protect against the far more common attack vector of "username on post-it note", "password = sex", etc.
The most common way to improve on "username/password" is to require users to have something physical.