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

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

理想的情况是:

• 根本不存储密码(甚至加密).存储从密码派生的哈希值.
• 盐的口令,以防止彩虹攻击.
• 将哈希放在单独的数据库服务器上,在自己的防火墙和自己定义良好的API ¹后面.这个API应该只做三件事:
  1. 对于给定的用户名,检索相应的密码哈希.
  2. 对于给定的用户名,请设置新哈希(以支持重置密码).
  3. 删除给定的用户名及其哈希值(以支持用户取消注册).
• 为盐做同样的事情:将它们放在自己的服务器上,并放在自己的防火墙和API之后.这个API应该只做三件事:
  1. 对于给定的用户名,检索相应的salt.
  2. 对于给定的用户名,将新盐设置为随机值(以支持重置密码).
  3. 删除给定的用户名及其盐(以支持用户取消注册).
• 散列和salt服务器都应该从世界(以及彼此)切断,并且只能从运行Web应用程序的服务器(即PHP或ASP.NET或其他......)访问.

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

• 确保通过HTTPS完成此操作,以便输入的数据安全地到达您的服务器.
• 调用API来检索用户名的密码哈希值.
• 调用用于检索用户名的salt的API.
• 对用户输入的密码进行salt并哈希,并将其与检索到的哈希进行比较.
• 如果匹配,则授予用户访问权限.

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

顺便说一下,登录是一种相对罕见的操作,因此除非你完全忽视正确的索引,否则不太可能造成性能瓶颈.

¹例如,实现Web服务,然后只打开该Web服务所需的端口,而不打开任何其他端口.