将用户名和密码存储在两个数据库中还是一个数据库中哪个更好？
我很好奇大家的想法。
这个想法是将单向加密的用户名存储在一个由一个连接保护的数据库中，然后将相应的单向加密密码存储在另一个具有不同 .它们可以是单独的服务器，但我认为没有必要。结果是，如果攻击者在没有访问另一个数据库的情况下获得了对一个数据库的访问权限，那么这些信息将毫无用处。 然后，使用该信息的应用程序将仅检查匹配的散列用户凭据以及索引列是否匹配。
我意识到可能存在一些性能问题，但我认为这些问题是最小的。对我来说，这将是最安全的用户信息。
I'm curious to see what everyone thinks.
The idea is to store the one-way encrypted username in one database secured by one connection then the coresponding one-way encrypted password in another database with a different . They could be seperate servers, but I don't think it would be neccessary. The result would be that if an attacker gained access to one database without the other the information would be useless.
Then the application that uses the information would only check for matching hashed user credentials and that an indexing column matched.
I realize there might be some performance issues, but my thought is that they would be minimal. To me this would be the most secure the user information could be.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我将密码存储在一个单独的、受限制的数据库中。为了增加你的理由，用户、组和一些其他设置的列表可以是公开的，而密码，即使是加密的，也应该得到很好的保护。例如，类 UNIX 系统通常存储用户特定的信息（例如用户 ID、组 ID、shell 等）。在公共场所。然而，密码的 MD5 哈希值对所有人都是隐藏的。以前它们是可用的，但现在这是一个很大的安全风险，因为现在可以使用暴力解码 MD5。
I'd store passwords in a separate, restricted database. To add to your reasons, list of users, groups and some other settings could be public while passwords, even though encrypted, should be well protected. For example, UNIX-like systems usually store user-specific information (such as user ID, group ID, shell etc). in publicly available place. However, MD5 hashes of passwords are hidden from everyone. Before they used to be available, but that is a great security risk these times because decoding MD5 is now possible by using brute-force.
根据我有限的知识......我猜想在对用户名和密码进行哈希处理后的任何内容都将是矫枉过正，并且从那里你就相当不错了。
From my limited knowledge... I would guess anything after hashing both the username and password would be overkill and that you are pretty good from there.
有趣的概念，尽管我使用过的每个系统都在单个模式中处理，甚至在同一个表中处理。确实可以，但没有必要像您提到的那样。
Interesting concept, although every system I have worked with has handled both in a single schema, same table even. Really it is possible, but not necessary like you mentioned.