简介
安全地散列密码的一种常见技术是使用盐和胡椒。 Salt来自数据库，Pepper来自服务器。 这意味着加盐和胡椒都是服务器端操作。
情况
在对密码进行哈希处理时，我更喜欢在应用盐和胡椒粉后进行哈希处理，因为使用简单的串联或类似的字符串注入将盐和胡椒粉应用到已经存在的哈希值上会产生模式，使黑客能够非常轻松地提取盐和胡椒粉来自哈希值。
问题
但是盐和胡椒之后的散列问题在于，这意味着散列需要在服务器端进行。这随后意味着您在服务器上仍然拥有纯文本密码，因为它尚未经过哈希处理，这意味着纯文本密码已通过 http(s) 请求传输。
这使得它看起来相当粗略。如果黑客能够解密 https 请求，我宁愿公开哈希值，而不是明文。但是从客户端发送哈希值是不可能的，因为客户端没有盐和胡椒。
我的解决方案（这就是我想验证的）
我的解决方案的想法是在客户端上对密码进行哈希处理，无需加盐和胡椒。然后将其发送到服务器，然后服务器将这个散列与盐和胡椒连接起来，然后再次散列整个内容。
这个“双重哈希”真的是一个东西吗？否则这是如何完成的？
发送到服务器的密码哈希而不是“明文”密码并不比哈希源（“明文”密码）更好。
当哈希值被盗时，小偷可以简单地将其发送到服务器而不是登录密码。
唯一的微小优势是，如果用户在多个服务上具有相同的密码，则您只能在使用相同哈希算法并且接受哈希而不是明文密码的服务上使用哈希来破解用户。盐和胡椒会进一步降低这种风险。
但这并不能提高“您的”服务的安全性。您仍然需要注意密码散列仅在服务器内存中保留极短的时间。
相反，如果没有您建议的盐和胡椒双重哈希，您甚至可以在用户数据库中存储某种明文密码进行比较。
因此，使用双重哈希，您只能使用胡椒来防止去哈希攻击，因为盐甚至与用户和双重哈希密码一起存储。与发送明文密码并在服务器上用盐和胡椒对其进行哈希处理以与存储的内容进行比较相比，这降低了安全性。