JavaScript密码哈希的发明者在这里

早在 1998 年，我正在建立一个 Wiki，这是我建立的第一个使用登录系统的网站。我无法负担使用 SSL 的托管费用，但我担心明文密码会在 Internet 上传输。我读过 CHAP（挑战哈希认证协议），并意识到我可以在 JavaScript 中实现它。我最终将JavaScript MD5作为一个独立项目发布，它已成为我开发的最受欢迎的开源项目。wiki 从未超越 alpha。

与 SSL 相比，它有许多弱点：

• 仅防止被动窃听。活跃的 MITM 可以篡改 JavaScript 并禁用散列。
• 服务器端哈希成为密码等价物。至少在通用实现中；有一些变化可以避免这种情况。
• 捕获的哈希可以被暴力破解。理论上可以使用 JavaScript RSA 避免这种情况。

我总是预先说明这些限制。我曾经定期为他们发火。但我至今仍坚持最初的原则：如果你因为某种原因没有获得 SSL，这比明文密码要好。在 2000 年代初期，许多大型提供商（最著名的是雅虎！）使用它进行登录。他们认为 SSL 即使只是用于登录也会有太多的开销。我认为他们在 2006 年切换到 SSL 只是为了登录，而在 2011 年左右 Firesheep 发布时，大多数提供商切换到完整的 SSL。

所以简短的回答是：客户端散列很少见，因为人们使用 SSL。

客户端散列仍然有一些潜在的好处：

• 有些软件不知道它是否会使用 SSL 部署，因此包含散列是有意义的。vBulletin 就是一个常见的例子。
• 服务器缓解——使用计算量大的散列，客户端做一些工作是有意义的。看到这个问题。
• 恶意管理员或受损服务器 - 客户端散列可以阻止他们看到明文密码。这通常被忽略，因为他们可以修改 JavaScript 并禁用散列。但公平地说，这种行为增加了他们被检测到的机会，所以这样做有一些好处。

归根结底，尽管这些好处微不足道，而且增加了很多复杂性——但在尝试提高安全性时，确实存在引入更严重漏洞的风险。对于想要比密码更安全的人来说，多因素身份验证是一个更好的解决方案。

所以第二个简短的答案是：因为多因素身份验证提供了比客户端密码哈希更高的安全性。

要理解这个问题，首先你必须了解我们为什么要散列密码。完全可以将密码以纯文本形式存储在服务器上，然后简单地将传输的密码与接收的密码进行比较。只要密码在传输过程中受到保护，这就是一种安全的身份验证方式（共享密钥）。

对密码进行哈希处理的原因是问题不在于身份验证，而在于存储。如果服务器遭到入侵，攻击者将立即访问所有用户帐户，因为他们现在知道用于用户身份验证的秘密。

散列是这方面的障碍。由于服务器不知道进行身份验证所需的实际输入，因此即使是对数据库的妥协也不会授予攻击者对用户帐户的访问权限。他们仍然需要找出输入以达到应用程序检查的哈希值。当然，他们可以将所有值更改为他们知道的值，但这会迅速引起怀疑，系统将被关闭并保护。

因此，客户端散列的问题在于它有效地使散列的结果成为密码而不是密码。没有什么可以阻止攻击者绕过官方客户端，直接将完成的哈希发送到服务器。它在身份验证期间没有提供额外（或损失）的安全性，但是在哈希旨在防止的情况下，它什么也没提供，因为存储在数据库中的哈希实际上是传输到服务器的共享秘密。

也就是说，客户端散列确实给您带来了两件值得注意的事情。虽然它根本无助于保护您的系统，但它可能有助于保护您的用户。如果您不安全地传输密码或传输受到损害而客户端代码未受到损害，您仍将保护用户的密码（他们可能在其他站点上重复使用）不被泄露。

另一个是您可以提供额外的哈希迭代，以使针对数据库的离线攻击更加困难，而无需使用服务器周期（同时还延长“客户端提交的中间密码”的长度），但您仍然需要足够的服务器周期来保护加长的密码免受恶意客户端的攻击。同样，此提供的主要保护是防止原始密码被发现，但无助于保护您网站的身份验证机制。

换句话说，虽然它确实提供了一些次要的保护，但从服务器的角度来看，客户端哈希应该被视为用户的直接密码。 它在服务器上提供的安全性不比用户直接提供密码并且应该受到保护。

如果您希望能够提供额外的安全级别，我会推荐两个哈希。散列一次客户端以构建一个新的唯一密码，然后在服务器上散列该密码以生成您存储在数据库中的值。这样，您就可以两全其美。

在大多数情况下，SSL 被充分信任以保护交换，尽管传输之前的初始哈希被认为是不必要的，但受感染的服务器总是可以更改发送给客户端的代码，从而不执行初始哈希。它根本不是 SSL 的有效替代方案，并且没有提供足够的额外优势来值得成本和复杂性。

如果你有很多优点，那么你应该在你的问题中列出它们，这样人们就会发现它们是否真的有用（如果有用，你可能会成名；）

人们不喜欢客户端散列，因为他们有更好的方法来保护用户的私人信息。让我们考虑一下可能存在信息泄漏的地方，其中有三个：

• 客户端。
• 在客户端和服务器之间。
• 服务器。

然后让我们看看为什么或为什么不客户端散列会在这些地方有所帮助。

• 客户端。

  如果您自己的计算机上存在恶意软件，例如，如果您的浏览器被入侵或您的计算机被植入了键盘记录软件，客户端哈希不会阻止黑客获取您的密码。原因很明显。

• 在客户端和服务器之间。

  客户端和服务器之间存在通信通道。如果有窃听者监听通信，那么客户端散列可以使密码泄露更加困难，因为窃听者必须从其散列中恢复原始密码。这里确实有用。

  但是，此漏洞是基于不安全的通信渠道的假设。实际上，有些协议的存在试图准确地解决这个问题。他们的主要任务是在不安全的通道上建立安全通道。最著名和广泛部署的示例是 SSL/TLS，它提供了比客户端散列更多的功能和更好的安全性。

  结论是客户端散列在通道中很有帮助，但这里有更好的工具。

• 服务器。

  如果服务器被黑客入侵，用户信息可能会在服务器上泄露。如果用户密码以明文形式存储，黑客可以从数据库中获取用户密码。这就是为什么今天大多数服务器不这样做的原因。相反，它们存储密码的哈希值，这样黑客就不能轻易地从他们手头的信息（即哈希值）中恢复原始密码。

  如果服务器只是存储在客户端计算的哈希值，您可能会相信事情仍然可以正常工作。但这是严重错误的。在这种情况下，哈希本身就成为密码等价物。黑客可以通过简单地交出哈希而不反转它来通过身份验证。黑客的目标不是反转哈希，而是闯入您的帐户。重要性在于服务器对客户端数据的验证过程，而不是数据是哈希值这一事实。因此，客户端散列的好处在这里是微不足道的，服务器无论如何都必须重新散列。

总而言之，客户端散列有助于保护用户信息，但这种保护主要适用于通信渠道。由于我们在那里有更好的方法（SSL/TLS），因此客户端散列的应用受到了极大的抑制。它根本不是手头任务的最佳工具。

最好在客户端进行哈希处理，然后在服务器端对密码进行加盐并再次进行哈希处理。这是针对中间人攻击的额外保护层。SSL 是第一层，但斯诺登的披露清楚地表明，SSL 可以相对容易地被 NSA 等组织破坏。