https上的客户端哈希/盐

Question

我想知道以下设置有什么严重问题：

用户名/密码登录方案JavaScript/Ajax请求服务器的盐值（我们已经在先前的问题中建立了盐不是秘密值）JavaScript预先预示了密码和盐的SHA1（或其他）。 JavaScript/Ajax将哈希返回服务器，服务器应用了通过AJAX发送的另一个盐/顶部。

交易超过HTTP。

我担心可能存在的问题，但不能说服自己，这是一个不好的设置。假设所有用户需要启用JavaScript，因为网站上大量使用了jQuery。基本上，它试图在密码的平坦文本中添加额外的安全层。

Answer 1

客户和服务器之间的盐和哈希的所有工作已经内置在基础HTTPS/SSL协议中。如果JavaScript中的安全层将非常有帮助，我会感到非常惊讶。我建议保持简单，并在客户端上使用SSL的明文。担心服务器端上的加密。

Answer 2

一如既往：对自己设计加密协议非常谨慎。

话虽这么说，我可以看到该计划的优势。它 将要 防止通过中间人攻击揭示的密码， 将要 确保服务器永远不会看到实际密码，从而防止某些内部攻击。另一方面，它不能防止浏览器，钓鱼等。

您可能想通读 RFC 2617 关于HTTP Digest访问身份验证。该方案与您的建议相似。

Answer 3

这不会添加任何其他安全性。客户端中存在JavaScript代码，因此已知哈希算法。在这种情况下，您将无法进行客户端哈希。

另外，没有理由为什么客户应该知道哈希盐。实际上 应该 成为一个秘密价值，尤其是在使用共享盐时。

Answer 4

您什么都没有。如果Joe Public可以通过单击“视图”>源看到盐，而旧的格言则是无关的，而旧的格言对永不信任的客户输入是密码哈希的两倍。

如果您真的想提高安全性，请使用基于SHA-2的哈希（SHA-224/256/384/512），因为SHA-1具有潜在的漏洞。 NIST不再向易受碰撞攻击（例如密码哈希）的应用程序推荐SHA-1。

Answer 5

我将100％不同意接受的答案，并说在任何情况下都不会离开客户。它应该始终被腌制和哈希。总是没有例外。

两个原因...。客户端不应依靠所有服务器组件和内部网络都是TSL。 TSL端点是一个负载平衡的反向代理，它使用明文与应用程序服务器进行通信是很常见的，因为DevOps不愿意为其所有内部服务器生成服务器证书。

. 。许多用户在病理上倾向于为其所有服务使用通用密码。服务器具有明文密码的事实，即使仅在内存中也使其成为外部攻击的吸引力。