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