通过HTTPS进行客户端哈希/盐析

Question

我想知道以下设置存在哪些严重问题：

用户名/密码登录方案 Javascript / ajax从服务器请求salt值（我们在之前的问题中建立了salt不是秘密值） Javascript预先生成密码和salt的SHA1（或其他）。 Javascript / ajax将哈希值返回给服务器 服务器在通过ajax发送的那个上应用另一个salt / hash。

交易通过HTTPS进行。

我担心可能存在的问题，但无法说服自己这是一个糟糕的设置。假设所有用户都需要启用javascript，因为jQuery在网站上被大量使用。它基本上是在为密码的纯文本添加额外的安全层。

Answer 1

一如既往：自己设计加密协议要非常小心。

但话虽如此，我可以看到该计划的优势。它将保护免受通过中间人攻击泄露的密码，将 确保服务器永远不会看到实际的密码，从而防止一些内部攻击。另一方面，它不能防止浏览器中的人，钓鱼等。

您可能希望阅读有关HTTP摘要访问身份验证的RFC 2617。该计划与您的建议类似。

Answer 2

在客户端和服务器之间传递salt和哈希的所有努力都已构建到底层的HTTPS / SSL协议中。如果javascript中的安全层非常有用，我会非常惊讶。我建议保持简单，并在客户端使用明文而不是SSL。担心服务器端的加密问题。

Answer 3

这不会增加任何额外的安全性。 JavaScript代码存在于客户端中，因此哈希算法是已知的。在这种情况下，您不会从客户端哈希获得任何好处。

此外，客户端没有理由知道散列盐。它实际上应该是一个秘密值，特别是如果你使用的是共享盐。

Answer 4

你没有得到任何东西。如果Joe Public可以通过点击View＆gt;看到它是没有意义的。对于密码散列来说，源代码和永不信任客户端输入的旧格言是双倍的。

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

Answer 5

我会100％不同意接受的答案，并说在任何情况下都不应该有一个原始密码永远离开客户端。它应该总是盐渍和散列。永远，无一例外。

两个原因...... 。客户端不应该依赖所有服务器组件和内部网络都是TSL。 TSL端点通常是负载平衡反向代理，它使用纯文本与app服务器通信，因为devops不会为所有内部服务器生成服务器证书而烦恼。

。许多用户在病态上倾向于使用通用密码来进行所有服务。事实上，服务器具有明文密码，即使只是在内存中，也使其成为外部攻击的有吸引力的目标。