security - 我应该在将密码发送到服务器端之前对其进行哈希处理吗？

Question

我注意到大多数网站都会通过 HTTPS 将密码以纯文本形式发送到服务器。如果我将密码的哈希值发送到服务器，有什么好处吗？这样会更安全吗？

Answer 1

这是一个老问题，但我觉得有必要就这个重要问题发表我的看法。这里有很多错误信息

OP 从未提及通过 HTTP(仅限 HTTPS)以明文形式发送密码，但许多人似乎出于某种原因回应了通过 HTTP 发送密码的问题。也就是说:

我认为密码永远不应该以纯文本形式保留(更不用说传输)。这意味着不保存在磁盘上，甚至不保存在内存中。

这里回复的人似乎认为 HTTPS 是 Elixir ，但事实并非如此。然而，它确实有很大帮助，并且应该在任何经过​​身份验证的 session 中使用。

确实不需要知道原始密码是什么。所需要的只是一种基于原始文本生成(并可靠地重新生成)身份验证“ key ”的可靠方法由用户选择。在理想的情况下，该文本应该通过加盐立即生成一个“ key ”，然后使用故意缓慢的散列算法(例如bcrypt，以防止暴力破解)对它进行不可逆散列。 。所述盐对于生成的用户凭证应该是唯一的。该“ key ”将成为您的系统用作密码的内容。这样，如果您的系统将来受到损害，这些凭据将只对您自己的组织有用，而不会在用户偷懒并使用相同密码的其他地方有用。

所以我们有一把 key 。现在我们需要清除客户端设备上的密码痕迹。

接下来我们需要获取您系统的 key 。您永远不应该“以明文形式”传输 key 或密码。甚至不通过 HTTPS。 HTTPS 并非坚不可摧。事实上，许多组织都可以成为可信的 MITM——不是从攻击的角度，而是对流量进行检查以实现自己的安全策略。这会削弱 HTTPS，而且它并不是发生这种情况的唯一方式(例如重定向到 HTTP MITM 攻击)。永远不要假设它是安全的。

为了解决这个问题，我们使用一次性随机数加密 key 。
对于每次向系统提交 key ，此随机数都是唯一的 - 即使在同一 session 期间使用相同的凭据(如果您需要多次发送它)。一旦它到达您自己的系统，您就可以反转所述随机数(解密)以恢复身份验证 key ，并对请求进行身份验证。

此时，我将不可逆地对其进行最后一次哈希处理，然后再将其永久存储在您自己的系统中。这样，您就可以出于 SSO 等目的与合作伙伴组织共享凭证的盐，同时能够证明您自己的组织无法冒充用户。这种方法最好的部分是，未经用户授权，您永远不会共享用户生成的任何内容。

进行更多研究，因为它的内容比我透露的还要多，但如果您想为用户提供真正的安全性，我认为此方法是目前最完整的响应。

TL；博士:

使用 HTTPS。每个密码使用唯一的盐，不可逆地安全地散列密码。在客户端上执行此操作 - 不要传输其实际密码。将用户原始密码传输到您的服务器永远不是“OK”或“Fine”。清除原始密码的所有痕迹。使用nonce无论 HTTP/HTTPS。它在很多层面上都更加安全。 (对OP的回答)。