为什么客户端的密码哈希很罕见？

#1 楼

JavaScript密码哈希的发明者

早在1998年，我就建立了一个Wiki，这是我用登录系统建立的第一个网站。我无法负担得起使用SSL托管的费用，但我担心通过Internet传输的纯文本密码。我读了有关CHAP（挑战性哈希身份验证协议）的文章，并意识到我可以在JavaScript中实现它。我最终将JavaScript MD5作为一个独立项目发布，并且它已成为我开发的最受欢迎的开源代码。 Wiki从未超越alpha。

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


仅可防止被动窃听。处于活动状态的MITM可以篡改JavaScript并禁用哈希。
服务器端哈希成为等效的密码。至少在通用实现中；可以避免这种情况。
被捕获的哈希值可能被强行使用。从理论上讲，使用JavaScript RSA可以避免这种情况。

我总是在前面提到这些限制。我曾经定期为他们发火。但是直到今天，我仍然坚持原来的原则：如果您出于某种原因未获得SSL，那将比纯文本密码更好。在2000年代初期，许多大型提供商（最著名的是Yahoo!）都使用此软件进行登录。他们认为，即使仅用于登录的SSL也会有太多开销。我认为他们仅在2006年就登录使用SSL，而在2011年Firesheep发布时，大多数提供程序都切换到了完全SSL。而是使用SSL。

客户端哈希还具有一些潜在的好处：


某些软件不知道是否将使用SSL进行部署。 ，因此包含散列是有意义的。 vBulletin是这种情况的常见示例。
服务器缓解-具有计算量大的哈希值，对于客户端来说，做一些工作是有意义的。看到这个问题。
恶意管理员或受感染的服务器-客户端哈希可以阻止他们看到纯文本密码。通常会取消此操作，因为他们可以修改JavaScript并禁用哈希。但公平地说，这种行动增加了他们被发现的机会，因此对此有一些好处。

尽管这些好处最终很小，而且增加了很多复杂性-您确实面临着以下风险：在尝试提高安全性时会引入一个更严重的漏洞。对于需要比密码更高的安全性的人，多因素身份验证是更好的解决方案。

第二个简短的答案是：因为多因素身份验证比客户端密码哈希更安全。 br />

#2 楼

要了解此问题，首先您必须了解我们为什么对密码进行哈希处理。完全有可能以纯文本格式将密码存储在服务器上，并将发送的密码与收到的密码进行比较。只要在传输过程中保护密码，这就是一种安全的身份验证方法（共享机密）。

密码被散列的原因是因为问题不是身份验证，而是存储。如果服务器受到威胁，攻击者将立即访问所有用户帐户，因为他们现在知道用于验证用户身份的机密。

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

因此，客户端哈希处理的问题在于，它有效地使得哈希的结果是密码而不是密码。没有什么可以阻止攻击者绕过官方客户端，而只是将完成的哈希直接发送到服务器。它在身份验证期间不会提供任何额外的（或损失）安全性，但是在哈希旨在防止的情况下，由于存储在数据库中的哈希实际上是传输到服务器的共享机密，因此它没有任何作用。
就是说，客户端哈希确实为您提供了两个值得注意的功能。尽管它根本无法帮助保护您的系统，但可能可以帮助保护您的用户。如果您不安全地传输密码或在不破坏客户端代码的情况下破坏了传输，您仍然可以保护用户密码（他们的密码可以在其他站点上重复使用）免受泄露。

您可以提供哈希的其他迭代，从而在不使用服务器周期的情况下使对数据库的脱机攻击更加困难（同时还延长了“客户端提交的中间密码”的长度），但是您仍然需要足够的服务器周期保护加长密码以防恶意客户端。同样，此方法提供的主要保护措施是防止发现原始密码，但它无助于保护站点的身份验证机制。从服务器的角度来看，应将客户端哈希视为用户的直接密码。与用户直接提供密码并应受到保护一样，它在服务器上提供的安全性没有或多或少的不足。

如果您希望能够提供额外的安全性，我将建议两个哈希。哈希一次客户端以构建一个新的唯一密码，然后将该密码哈希到服务器上以使值存储在数据库中。这样一来，您可以两全其美。

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

#3 楼

如果您有很多优点，则应在问题中列出它们，以便人们了解它们是否真正有用（如果这样，您可能会成名；）

人们不喜欢客户端哈希，因为它们具有保护用户私人信息的更好方法。让我们考虑一下存在潜在信息泄漏的地方，其中有三个：


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

然后让我们看看为什么客户端哈希在这些地方会有所帮助。



客户端。

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


在客户端和服务器之间。

客户端和服务器之间存在通信通道。如果有一个窃听者在监听通信，则客户端哈希可以使密码泄漏更加困难，因为窃听者必须从其哈希中恢复原始密码。

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


服务器。

如果服务器被黑客攻陷，则用户信息可能会在服务器上泄漏。如果用户密码以明文形式存储，则黑客可以从数据库中获取用户密码。这就是为什么今天大多数服务器不这样做的原因。而是存储密码的哈希值，以使黑客无法轻易地从手头的信息中还原原始密码（即哈希值）。存储在客户端计算的哈希值。但这是严重错误的。在这种情况下，散列本身变成了密码等效项。黑客可以通过简单地移交哈希而不反转哈希来通过身份验证。黑客的目标不是反转哈希，而是闯入您的帐户。重要性在于服务器对客户端数据的验证过程，而不是数据是哈希值。因此，客户端哈希处理的好处在这里是微不足道的，并且服务器无论如何都必须重新哈希。


总而言之，客户端哈希处理有助于保护用户信息，但是这种保护在很大程度上适用于沟通渠道。由于我们在那里有更好的方法（SSL / TLS），因此客户端哈希的应用受到了极大的压制。这根本不是解决当前任务的最佳工具。

#4 楼

优良作法是在客户端进行哈希处理，然后对密码加盐并在服务器端再次进行哈希处理。这是针对中间攻击中人的额外防护层。 SSL是第一层，但是Snowden的启示明确表明SSL可以相对容易地被NSA等组织破坏。

#5 楼

客户端密码散列有什么优势？

密码不会以明文形式通过网络发送。但是登录时确实应该使用TLS加密，因此密码嗅探不会成为问题。

另一个原因可能是您不希望服务器知道用户密码，甚至不会持续一微秒。这意味着您在注册时为服务器提供了密码哈希，然后使用该密码哈希登录。不幸的是，这并不能解决任何问题：登录帐户的共享机密现在是哈希，而不是密码。当您了解哈希值后，就可以在不知道实际密码的情况下登录（因为服务器也不知道该密码）。

#6 楼

由于您正在谈论Web应用程序...

在数据库中，我们有一个表调用dbo.useracc，我们将这些哈希值存储在密码中。

User        Password
--------       ----------
user1       5f4dcc3b5aa765d61d8327deb882cf99
user2       202cb962ac59075b964b07152d234b70
user3       098f6bcd4621d373cade4e832627b4f6

和我们在Web应用程序中的登录功能类似

if (user == $user and password == $pass) {
           return auth.token
}

假设攻击者成功入侵并窃取了数据库并保存了dbo.useracc数据。现在，他已经有了我们的哈希密码。发送您的哈希密码，他仍然可以登录。请记住，您的应用程序数据在经过哈希处理以进行检查之后最终会通过POST方法与服务器进行通信。

但是，如果哈希处理在服务器中，则是另一回事了。

$pass = md5.hash($pass);

if (user == $user and password == $pass) {
           return auth.token;
}

如果黑客使用哈希密码登录，则将使用哈希密码对哈希密码进行检查。

在这种情况下，假设攻击者发布

$ user = user1
$ pass = 5f4dcc3b5aa765d61d8327deb882cf99

在服务器端执行$ pass = md5.hash（5f4dcc3b5aa765d61d8327deb882cf99）它将返回'696d29e0940a4957748fe3fc9efd22a3'，这将返回错误的语句。使用哈希密码。当然，如果攻击者通过字典攻击成功地对暴力破解/破解了哈希，那么攻击者仍然可以入侵这些帐户。但是，如果密码在破坏系统后是一个好的密码，则黑客需要更长的时间，并且服务器管理员可以重置密码并向用户发送电子邮件。

此外，它还用于应对内部威胁，例如企业中的员工。在企业中，将有数据库管理员和开发人员。他们是不同的角色。现在，为了防止员工用户访问敏感数据，他们需要同时访问应用程序和数据库才能访问数据。当然，您可能会争辩说，DBA仍然可以通过数据库本身来更改数据库数据，但是开发人员无法访问它，并且更容易确定攻击的来源。它与访问控制权有关，并将风险和威胁降至最低。

#7 楼

尽管该主题有一些具体的泄漏点，如@Cyker所指出的，但这里的讨论还是有点轻快的。。。简而言之，如果您尽快进行哈希处理，则可以减少意外将明文密码传递到不应传递的地方的编程风险。我们已经采取了安全字符串和安全数组之类的措施来尝试尽快销毁明文。在获得密码的同时进行哈希运算是另一种类似的措施……随着代码的发展等，这种风险似乎仍在降低。

我只是写了一个C＃“ Box”，接受SecureString明文并立即对其进行哈希处理---这样，我只知道它永远不会被记录或传递给我不希望的库。这与协议无关，而只是程序员坐在这里看着密码---我不想触摸它！ （在某些方面，它仍然是等效的密码，但是至少可以立即将其隐藏起来，就像在链接的方法调用中移动右括号并将明文传递到错误的位置一样。而且仍然没有隐藏安全数组。） />

#8 楼

我打算以权衡明确的目的加入到这里，以支持客户端哈希机制。让我们看看这对我们有何好处：

客户端：
没有任何改进。

传输中：
在SSLstrip情况下保护密码密码最终以明文形式传输。但是，如果实施了HSTS，那么大多数人会说SSLStrip将不起作用。是吗？
否。

进入服务器时：
最后，我们看到了最大的好处。如果有人破坏了服务器怎么办？如果他们只是启动Wireshark / TCPDump并导出服务器的私钥，他们将获得连续的明文密码流。现在，他们可以坐在网络上几个月，而对于高容量的服务器（每月数百万个用户注册），他们将遇到大量纯文本漏洞。当然，这是假定为服务人员获取密码比在服务器上拥有RCE更具价值。

在服务器上：
如果没有，性能优势不必在每个输入的密码上运行bcrypt，这样就可以在不引入任何新漏洞的情况下，将一些计算量分担给客户端。对于服务器管理员和硬件成本来说，这似乎是一件好事。

看起来，最佳实践似乎是将密码哈希合并到客户端，除非它会造成无法忍受的页面加载时间为用户。

#9 楼

我同意如果可以使用SSL / TLS，则客户端哈希保护身份验证过程的优势将受到限制。
但是，如果攻击者可以访问存储的哈希值（此过程之后），则SSL / TLS无法解决针对自定义硬件攻击的漏洞。诸如简单的盐渍哈希之类的功能或诸如PBKDF2之类的功能由于对内存的需求低而非常容易受到这些攻击。受这些方案保护的密码破解既便宜又快速。这至少是密码哈希处理的主要问题之一。

乍一看，这与客户端哈希处理与SSL / TLS无关-而是：
实现诸如Scrypt，Argon2或Catena之类的内存硬密码哈希方案以保护自定义硬件攻击，服务器的硬件需求急剧增加。因此，实际上，服务会降低内存硬度或切换到易受攻击的方案。客户端哈希可以帮助解决该问题。当客户端计算这些昂贵的（内存硬性）功能时，该服务可以使用它们而无需更好的硬件。

因此，现代密码哈希方案可以委托最昂贵的（内存硬性）功能部分功能提供给客户。此功能称为服务器缓解，由Argon2和Catena提供。

结论：使用现代的密码散列方案非常不容易受到自定义硬件的攻击，将来会增加或至少应该增加对客户端散列的使用，当然还有SSL / TLS。

#10 楼

我认为客户端哈希有一个弊端：

pro：在dns / phishing / whatthing的情况下，您可以隐藏密码，这对用户很有用，因为大多数人在多个密码上重复使用服务。正如其他开发人员所说，这对您自己的安全无济于事。

缺点：您的服务器未获得密码，这可以防止类似警告用户密码强度的事情。我知道有人会说这可以/应该是客户端，但是当您有多个客户端时，这可以很好地集中服务器端。

#11 楼

我认为客户端被黑客入侵的可能性高于服务器端。 （因为有一些IT专家照顾服务器）。如果您的计算机已经被黑客入侵。用来散列密码的客户端算法也可以被黑客窃取。尽快，您的算法不再是秘密。我认为，它变得无用了。