我了解 SSL/TLS 以及服务器端散列和加盐密码的好处，并计划使用此标准来确保密码安全，可能与 bcrypt 一起使用。
然而，我想知道的是，使用客户端 JavaScript 与上述最佳实践相结合，在通往服务器的途中加密或混淆密码是否有任何额外的优点。我用来证明考虑这一点的理由是管理员错误（未能启用 mod-rewrite 或错误的 vhost 配置）将来可能允许非 HTTPS 连接到我的服务器。如果他们设法在没有 SSL/TLS 的情况下进行连接，这将是一个额外的安全层来保护公共 WiFi 上的用户。
再次，只是想知道这种方法是否有优点，如果没有，为什么？
编辑：此外，我认为至少伪装甚至接收到登录表单（将表单服务器端编码为由客户端 javascript 解码，然后通过 DOM 显示）可能是有价值的，尤其是在面对有人只是在公共 WiFi 中窥探明文交易。
【问题讨论】：
标签： javascript security ssl client-side-scripting
虽然这样的方法可能有助于最随意的攻击者溜走，但它几乎完全不值得付出努力，实际上可能对整体安全性有些不利。
如果您的服务器接受这个经过混淆/散列/加密的密码作为用户密码，那么窃取它给攻击者带来的优势几乎与窃取用户的明文密码一样多；他们将能够以用户身份进行身份验证。他们甚至可以从混淆后的字符串中检索用户的明文密码，因为他们能够准确地看到对用户密码执行了哪些操作来混淆它。
此外，混淆登录表单几乎完全没有用；任何有兴趣的攻击者都能够在网络流量中找到登录序列，并且能够轻而易举地窃取用户的信息。它可能会欺骗诸如绵羊嗅探器之类的东西，但只要有人在某个地方编写检测您的登录序列的规则所需的时间就足够了。如果您有足够大的用户群，或者您的应用处理足够敏感的信息，那将是很短的时间。
简而言之，不要浪费时间尝试解决已经解决的问题；花时间确保您已正确配置独占 HTTPS。
【讨论】：
所以，经过大量阅读后，我整理了以下解释为什么这种技术没有优点：
复杂性是安全的敌人。如果系统的未来维护者不完全理解一种混淆方法，他们可能会开始依赖它，认为它提供了实际的安全性，而不是在实际的行业标准安全技术之外使用它。
除此之外，我的想法有缺陷，我相信在 TLS 失败之前没有人会试图绕过这种混淆。这不太可能是真的，因为在 TLS 失败之前解决混淆将有一个难以置信的优势以防将来独占 TLS 失败。
该技术会带来额外的成本，但保护很少，最坏的情况是会产生额外安全性的有害错觉，可能会鼓励系统维护人员较少关注确保正确的 TLS。
【讨论】：