Question

目前，我的系统在用户注册时使用自定义生成盐，然后将其与散列密码一起存储在数据库中。

现在，我正考虑让用户在注册时定义自己的盐。例如，如果他们访问register2，他们会看到3个输入：

Registerpage：

电子邮件

密码

自定义盐

所以他们填写他们的电子邮件，密码并设置自定义盐 - 无论他们想要什么，在哈希函数的限制内

$loginhash = hash_hmac('sha256',$password,$userdefinedsalt); //just for the post don't use

现在，因为他们的用户已经生成了自己的盐，那个盐实际上并不存储在数据库中，只有哈希密码。

现在用户已经注册，每次他们想要登录时，他们必须指定他们创建的哈希定制盐，使用POST获取输入，将它们一起散列并比较密码。

因此，如果恶意黑客以某种方式找到进入数据库的方式，他们将拥有无用的哈希密码，并且没有盐，因此使该密码无用？是或否？

现在，如果另一个用户不喜欢这样做，他们可以去系统生成的盐的路径，存储在数据库等。

这似乎可以保护用户密码吗？

如果用户忘记了他们的盐会怎样？

他们可以进行密码重置，这将生成一个带盐的自定义哈希密码，然后他们可以登录，并再次执行用盐创建另一个密码的操作，这样做时，它会删除计算机生成的盐从数据库中留下那个空白。

这只是要求一个受伤的世界，这是一个坏方法吗？

Answer 1

盐的目的是防止攻击者用一张彩虹表获取所有密码，仅此而已。因此，让盐更好地工作，不要混淆不同的目标。让用户选择他自己的盐甚至可能会损害安全性，因为用户可以选择一种不太独特或太短的弱盐。

要求用户定义的盐就像要求第二个密码一样，你不会这样做，不是吗？您可以以这种方式增加安全性，但之后我会使用第二个密码来加密（双向）计算出的密码哈希。

我认为更好的是定义服务器端强密钥，并使用它来加密密码哈希。然后攻击者不能暴力破解哈希，直到他在服务器上获得额外的权限来读取密钥。