目前，我的系统在用户注册时使用自定义生成salt，然后将其与哈希密码一起存储在数据库中。
现在，我正在考虑为用户提供一个选项，让他们在注册时定义自己的salt。例如，如果他们访问寄存器2，他们会看到3个输入：
注册页面：
电子邮件
密码
自定义盐
因此，他们填写了自己的电子邮件、密码并设置了一个自定义salt——无论他们想成为什么样的人，都在散列函数的限制范围内
$loginhash = hash_hmac('sha256',$password,$userdefinedsalt); //just for the post don't use
现在，因为他们的用户已经生成了自己的salt，所以salt实际上并不存储在数据库中，只存储散列后的密码。
现在用户已经注册，每次他们想登录时，都必须指定创建该哈希的自定义salt，使用POST获取输入，将它们散列在一起并比较密码。
因此，如果恶意黑客以某种方式找到了进入数据库的方法，他们将拥有一个无用的哈希密码，并且没有salt，从而使该密码变得无用？是还是不是？
现在，如果另一个用户不想这样做，他们可以按照系统生成的盐的路线，将其存储在数据库等中。
这对于保护用户密码来说似乎是可以接受的吗？
如果用户忘记了他们的盐怎么办
他们可以进行密码重置，这将生成一个带有salt的自定义哈希密码，然后他们可以登录，并再次执行使用salt创建另一个密码的操作，这样做时，它会从数据库中删除计算机生成的salt，将其留空。
这只是要求一个充满伤害的世界吗，这是一种糟糕的方式吗？
salt的目的是防止攻击者通过一个彩虹表获取所有密码。因此，最好让盐发挥作用，不要混淆不同的目标。让用户选择自己的盐甚至会损害安全性，因为用户可能会选择一种不唯一或太短的弱盐。
要求用户定义的salt就像要求第二个密码一样，你不会这么做，是吗？您可以通过这种方式提高安全性，但我会使用第二个密码来加密（双向）计算出的密码哈希。
在我看来，更好的方法是定义一个服务器端强密钥，并使用它来加密密码哈希。然后，攻击者不能强行使用哈希，直到他在服务器上获得读取密钥的额外权限。