客户端密码安全技术的优点

Question

我了解SSL / TLS的好处以及服务器端的散列和密码密码，并计划将此标准用于密码安全，可能使用bcrypt。

我想知道的是，使用客户端JavaScript结合上述最佳实践加密或混淆密码到服务器的途径是否还有其他优点。我以前用来证明这一点的理由是管理错误（无法启用mod-rewrite或错误的vhost配置）将来可能允许与我的服务器进行非HTTPS连接。如果他们以某种方式设法在没有SSL / TLS的情况下进行连接，这将是保护公共WiFi用户的额外安全层。

再次，只是想知道这种方法是否有用，如果没有，为什么？

编辑：此外，我发现至少伪装一个登录表单甚至被接收（编码表单服务器端要由客户端javascript解码然后通过DOM显示）可能是有价值的，尤其是当反对某人只是在公共WiFi中窥探纯文本交易。

Answer 1

虽然这样的方法可能有助于让最随意的攻击者失误，但这几乎完全不值得付出努力，实际上对整体安全性有些不利。

如果您的服务器接受此混淆/散列/加密密码作为用户密码，那么窃取它会使攻击者获得与窃取用户明文密码相同的优势;他们将能够以用户身份进行身份验证。他们甚至可以从混淆的字符串中检索用户的明文密码，因为他们可以准确地看到对用户的密码执行了哪些操作来对其进行模糊处理。

此外，混淆登录表单几乎完全没用;任何有兴趣的攻击者都能够在网络流量中找到登录顺序，并且能够轻松窃取用户的信息。它可能会愚弄像羊墙嗅探器一样的东西，但仅限于某人所需的时间，某处可以编写检测登录顺序的规则。如果您拥有足够多的用户群，或者您的应用处理的是足够敏感的信息，那么这将是非常短的时间。

简而言之，不要浪费你的时间来解决已经解决的问题;花时间确保您已正确配置独占HTTPS。

Answer 2

所以，经过大量的阅读后，我编写了以下解释为什么这种技术没有价值：

复杂性是安全的敌人。如果系统的未来维护者没有完全理解混淆方法，他们可能会开始依赖它，认为它提供了实际的安全性，而不是使用它而不是实际的行业标准安全技术。

除此之外，我的想法是有缺陷的，因为我认为在TLS失败之前没有人会试图绕过这种混淆。这不太可能是真的，因为如果独占TLS未来失败，那么在TLS失败之前解决混淆会有一个令人难以置信的优势

这种技术在很少的保护下会产生额外的成本，最坏的情况会产生额外安全性的有害幻觉，可能会鼓励系统维护人员更少关注确保正确的TLS。