发送密码的散列而不是未散列的密码是一个坏主意吗？

Question

例如，如果用户启用了JavaScript，我们会发送哈希密码并发送哈希值。如果没有，我们发送密码unhashed和一个标记，以标记它是未散列的。然后我们构建哈希（如果它没有被哈希）并将其与存储的哈希进行比较。

这似乎是安全和简单的。为什么它不是一种流行的密码发送方式？我错过了什么吗？

换句话说：为什么更好的是丢失哈希然后没有密码？ （我们大多数人只有很少的网站密码）

Answer 1

这里真正的问题是中间人攻击，有人嗅到线下的东西。如果您发送密码的哈希值或密码本身并不重要，如果下游有人可以读取此密码，他们可以以该人身份登录。唯一安全的选择是使用SSL来阻止除服务器以外的任何人解密密码哈希/密码。

Answer 2

JavaScript总是会被篡改。通过使用JavaScript散列密码，您至少会暴露有关如何存储密码的规则。从黑客的角度来看，捕获真实密码并将其发送给您的系统或捕获密码并将其发送到您的系统是一回事。

如果您确实需要提高密码安全性，我建议您使用https并在服务器端进行哈希处理。别忘了使用盐键。

Answer 3

然后我只是窃听哈希并用那个登录？

如果您担心安全问题，则应使用SSL。然后你可以按原样发送密码。

此外，SSL证明他们登录的服务器不是冒充你的人。

Answer 4

请注意，如果您只对密码进行哈希处理，则哈希值将完全相同 时间。

您应该在POP3协议中使用类似于APOP的某种挑战/响应机制

Answer 5

你的工作比现在更复杂。只需将密码作为纯文本发送，哈希就不会以任何方式提高安全性。 （见其他答案）

如果使用相同的散列算法在数据库中存储密码，实际上会降低安全性。因为如果某人可以从中获取哈希密码，他可以使用它们来验证自己。 （他不必去除它们）如果您的网站上有SQL注入或其他信息泄露问题，情况就是这样。

Answer 6

请参阅Perl/Javascript MD5 Secure User Authentication了解实施和讨论。

Answer 7

我的建议是发送哈希值。虽然您公开了内部安全机制，但它确实做了两件事。如果有人获得了哈希值，那么该人就知道您不会在您的系统中存储密码，并且可能会阻止您尝试窃取您的凭据存储库。其次，您正在保护最终用户的原始密码。即使有人获得了哈希，他们也没有原始密码，这可能允许他们绕过用户使用相同或类似密码的其他系统（salting会阻止哈希在别处使用）。此外，预先密码密码允许您在后端严格设置字符限制和字母数字验证。