存储用户并传递单个表或单独的表

和光启

2023-03-14

问题内容：

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

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

类型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 .

哪一个更好？

问题答案：

理想情况下：

根本不存储密码（即使是加密的）。存储从密码派生的哈希。
给密码加盐以防止彩虹攻击。
将散列放在单独的数据库服务器上，位于其自己的防火墙和其定义良好的API 1之后。该API应该只做三件事：
1. 对于给定的用户名，检索相应的密码哈希。
2. 对于给定的用户名，设置新的哈希（以支持重置密码）。
3. 删除给定的用户名及其哈希（以支持用户注销）。
对盐执行相同的操作：将它们放在自己的服务器上，并放在自己的防火墙和API之后。该API应该只做三件事：
1. 对于给定的用户名，检索相应的盐。
2. 对于给定的用户名，将新盐设置为随机值（以支持重置密码）。
3. 删除给定的用户名及其盐（以支持用户注销）。
哈希服务器和Salt服务器都应该与世界隔离（并且彼此隔离），并且只能从运行Web应用程序的服务器（即PHP或ASP.NET或其他任何服务器）访问。

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

从本质上讲，哈希是不可逆的-
除了用户以外，没有人（甚至没有您）知道确切的密码。万一用户忘记了密码，您不能将密码发送给他们，但是您可以允许他们重设密码，前提是他们通过了一些其他验证（例如，可以访问特定的电子邮件地址和/或回答机密信息）问题）。

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

1 例如，实施一个Web服务，然后仅打开该Web服务所需的端口，然后再打开其他端口。