Question

我想为我的网站创建一个用户管理系统，

什么是更好的安全性和性能。

类型1：

table_user : user_id , user_name , user_email , user_password . user_phone ...

或

类型2：

table_user : user_id , user_name , user_email ...
table_pass : user_id , user_password .
table_phone: user_id , user_phone .

哪一个更好？

Answer 1

理想情况下：

根本不存储密码（甚至加密）。存储从密码派生的哈希。
Salt密码以阻止rainbow attacks。
将哈希值放在单独的数据库服务器上，位于自己的防火墙和自己定义良好的API ¹之后。这个API应该只做三件事：
1. 对于给定的用户名，请检索相应的密码哈希。
2. 对于给定的用户名，请设置新哈希值（以支持重置密码）。
3. 删除给定的用户名及其哈希值（以支持用户取消注册）。
对盐做同样的事情：将它们放在自己的服务器上，放在自己的防火墙和API之后。这个API应该只做三件事：
1. 对于给定的用户名，请检索相应的salt。
2. 对于给定的用户名，请将新盐设置为随机值（以支持重置密码）。
3. 删除指定的用户名及其盐（以支持用户取消注册）。
hash和salt服务器都应该从世界（和彼此）切断，只能从运行Web应用程序的服务器（即PHP或ASP.NET或其他任何......）访问。

当用户通过输入用户名和密码尝试登录时：

就其本质而言，哈希是不可逆转的 - 除了用户之外，没有人，甚至是你，都不知道确切的密码。如果用户忘记密码，您无法向他们发送密码，但您可以允许他们重置密码，假设他们通过了一些额外的验证（即可以访问特定的电子邮件地址和/或回答秘密）问题）。

BTW，登录是相对罕见的操作，因此除非您完全忽略正确的索引，否则不太可能造成性能瓶颈。

¹例如实现Web服务，然后只打开该Web服务所需的端口，而不是其他任何内容。

Answer 2

我将使用选项1。

认为有十万用户。因此，要获取用户数据，您将不得不处理n个表而不是1个表，这显然会在服务器上添加LOAD，最后您将获得BAD PERFORMANCE。

所以，我会选择1。

对于电话。数字，添加字段作为landline_number，mobile_number，alternate_number作为表中的添加字段赢得了那么大的差异，然后为该字段添加表。

是的，根据Steve评论，使用安全散列机制存储密码。

那么您要选择哪个选项？

Answer 3

这取决于。如果您想保留密码历史记录，并且用户可以拥有多个电话号码，那么您可以为密码和电话创建其他表格。在其他情况下，一个表就足够了。

Answer 4

首先，正如@Steve评论一样，您应该使用安全散列机制存储密码 - 存储纯文本密码是不负责任的 - 这意味着任何可以入侵您系统的人都知道他们可能在其他网站上重复使用的用户密码。

其次，在任一设计中都没有固有的安全性或性能优势 - 从安全的角度来看，您必须假设可以访问您的数据库的攻击者可以运行查询，并且检索起来非常简单两种方案中的数据。从性能的角度来看，如果您有主/外键索引，则选项2中的连接成本不太可能重要。

如果您需要在一段时间后重新设置密码，并且需要存储密码历史记录以防止人们重复使用密码（例如，这是Windows支持的功能），您需要“ UserPassword“表，包含valid_from和valid_until列。