我目前正在为我们的客户开发一个带有PHP框架的平台。
客户IT部门的负责人希望我们使用包含电子邮件+密码+盐（散列）的一个数据库字段来处理身份验证，因此此表中没有纯文本电子邮件字段，密码更安全（他的推理） ）。用户应该能够使用他的电子邮件地址和密码登录。因此，电子邮件地址用作用户名
这背后的想法是用户的电子邮件地址对我们客户的业务非常重要，并且IT负责人希望在可能发生攻击的情况下模糊登录表中的电子邮件地址。 （例如，黑客可以访问登录表）
这当然只是可能的，因为登录的哈希电子邮件地址链接到他在配置文件表中的电子邮件地址。
此过程基本上有两个表可供使用。这些表当然在同一个数据库中 一个具有散列组合字段（email，pw，salt）和一个配置文件表的登录表，其中包含一个字段中明文的电子邮件。我们称之为profile_email。
我强烈建议不要使用此解决方案，因为我从未听说过这个问题，而且我已经确定了此解决方案可能存在的一些问题。
所以我的问题是：这是一个安全可行的解决方案吗？你能想到任何不可预见的问题吗？你听说过类似的解决方案吗？
答案 0 :(得分：0)
我不清楚你的情况，但我猜它是这样的：
valueToStore = hash(email) + delimiter + hash(password, salt) + delimiter + salt;
这将允许搜索电子邮件，但前提是电子邮件不区分大小写（例如小写）。否则你甚至可以使用相同的电子邮件地址获得重复。
由于散列电子邮件只是此字段的一部分，因此在数据库中搜索更加困难和缓慢。如果用户更改了他的电子邮件地址，则必须同时更新字段，密码表和profile_email表。
因为电子邮件无论如何都在另一个表中可用，所以为什么这应该更加安全是不可理解的。如果攻击者具有对数据库的读访问权（例如SQL注入），则没有什么可以阻止他查询其他表。
如果电子邮件在其他表中也加密（未散列），那将更安全。然后，您可以通过哈希搜索电子邮件，然后使用IV加密电子邮件。
在每种情况下，我都不会将散列电子邮件和密码哈希存储到单个字段中。如果散列正确，则其他参数（如成本因子和算法）也是密码哈希的一部分，这对于单个字段就足够了。
答案 1 :(得分：0)
来自实体 - 关系 - 观点...
你有一个登录表，其中包含一个散列哈希值的字段或一个字符串值连接的散列...
您有一个配置文件表，其中包含常用的个人资料信息，包括敏感信息（电子邮件）
如果这两者通过密钥链接，那么该电子邮件地址的简单散列是无用的，因为相同的信息可用作配置文件表中的明文字符串
在另一种情况下，当在登录表中它是电子邮件密码和盐的连接的一个哈希时，它没有增加安全性，因为到配置文件表的链接显示了哈希连接的一部分......你还必须存储盐，因为它也必须链接到登录实体或者是登录实体的一部分，攻击者知道除密码之外的所有部分...
我无法理解为什么这种方法是个好主意，除非你将数据库登录分开进行身份验证......
让我们说你有登录表：
S = randomSalt
E = cryptoHash（电子邮件，static_system_wide_salt）
P = cryptoHash（密码，S）
id = KeyForRelationToOtherEntities
现在这个表的数据库权限受到限制，只有authenticator_user可以访问它，但数据库的其余部分没有任何内容
身份验证过程中的电子邮件地址会受到彩虹化攻击的影响并加以强化
密码
您可以在登录过程中索引用于搜索的列表
验证者无法访问可以链接到登录实体的配置文件信息或其他信息，因为访问权限将验证者限制在登录表中
由于同样的原因，系统的其余部分无法访问登录表
如果验证者只能读取登录表，则必须考虑一个额外的角色，即密码更改和创建新用户
...这里只有我的2美分......它只是一个想法，而不是真正完整，或保证是安全的...只是一个想法，它提出了分离登录表的一般想法