Php 允许用户为其密码创建自己的salt

目前，当用户注册时，我的系统正在使用一个定制的生成salt，然后将其与哈希密码一起存储在数据库中

现在，我在考虑让用户在注册时定义自己的salt。例如，如果他们访问register2，他们会看到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就像请求第二个密码一样，你不会这么做的，是吗？您可以通过这种方式提高安全性，但是我将使用第二个密码来加密（双向）计算出的密码哈希

---

在我看来，更好的方法是定义服务器端强密钥，并使用它加密密码散列。然后，攻击者无法强制执行哈希，直到他在服务器上获得读取密钥的额外权限。

考虑到您没有将salt存储在数据库中，这看起来不是个坏主意。然而，什么样的人会使用这个系统，你的目标是谁？我的意思是，你确定他们喜欢它是因为他们会觉得更安全，还是你认为他们可能会觉得它比应该的更复杂？如果我看到一个网站在他们的注册页面上向我要盐作为密码，我会质疑他们的能力。如果我在他们的登录页面上看到它，我会关闭浏览器，忘记它们曾经存在过。永远。@IgnacioVazquez Abrams大多数人都会有同样的反应。向用户索要盐等同于要求用户定义两个密码。-没用的东西。