我想知道以下设置存在哪些严重问题：
用户名/密码登录方案 Javascript/ajax 向服务器请求盐值（我们在前面的问题中已经确定盐不是秘密值） Javascript 执行密码和盐的 SHA1（或其他）。 Javascript/ajax 将哈希返回给服务器 服务器在通过 ajax 发送的那个之上应用另一个 salt/hash。
交易通过 HTTPS。
我担心可能存在的问题，但无法说服自己这是一个糟糕的设置。假设所有用户都需要启用 javascript，因为网站上大量使用 jQuery。它基本上是在尝试为密码的纯文本添加额外的安全层。
【问题讨论】：
标签： javascript https login-script cryptographic-hash-function
一如既往：在自己设计加密协议时要非常小心。
但话虽如此，我可以看到该方案的优势。它将防止密码通过中间人攻击被泄露，它将确保服务器永远不会看到实际密码，从而防止一些内部攻击。另一方面，它不能防止浏览器中的人、钓鱼等。
您可能想通读RFC 2617 关于 HTTP Digest 访问身份验证的信息。该方案与您提出的方案相似。
【讨论】：
在客户端和服务器之间传递盐和哈希的所有工作都已内置到底层 HTTPS/SSL 协议中。如果 javascript 中的安全层会有很大帮助，我会感到非常惊讶。我建议保持简单，并在客户端使用基于 SSL 的纯文本。担心服务器端的加密。
【讨论】：
这不会增加任何额外的安全性。 JavaScript 代码存在于客户端中，因此散列算法是已知的。在这种情况下，您从客户端哈希中得不到任何好处。
此外，客户端没有理由知道哈希盐。它实际上应该是一个秘密值，尤其是在您使用共享盐时。
【讨论】：
我会 100% 不同意接受的答案，并说在任何情况下，原始密码都不应该离开客户。它应该总是加盐和散列。总是，无一例外。
两个原因... .客户端不应依赖所有服务器组件和内部网络都是 TSL。 TSL 端点作为负载平衡反向代理很常见，它使用明文与应用服务器通信，因为 devops 不会为所有内部服务器生成服务器证书。
。许多用户病态地倾向于为他们的所有服务使用一个通用密码。服务器具有明文密码这一事实，即使仅在内存中，也使其成为外部攻击的有吸引力的目标。
【讨论】：
你没有得到任何东西。如果 Joe Public 可以通过单击“查看”>“源”来看到它，那么添加盐就没有意义了，而且关于从不信任客户端输入的旧格言对于密码散列来说是双倍的。
如果您真的想提高安全性，请使用基于 SHA-2 的哈希 (SHA-224/256/384/512)，因为 SHA-1 存在潜在漏洞。 NIST 不再建议将 SHA-1 用于易受冲突攻击（如密码哈希）的应用程序。
【讨论】：