以纯文本或散列形式发送密码的原因主要是历史原因。在过去，当我们在串行线路（70 年代到 80 年代）上使用哑终端时，只能使用纯文本解决方案。像S/Key这样的一次性密码也存在，但您需要随身携带硬拷贝列表...

然后是PC，Windows和Lan Manager的时代。微软研究员知道以太网太容易被窥探，所以他们决定只交换挑战。对应的是在服务器上以可逆形式存储密码所必需的。

加密的使用随着 SSL 变得越来越流行，许多协议都适应了使用加密通道（例如 HTTP -> HTTPS）。管理员重新发现了仅在其服务器上存储散列的好处：如果密码数据库遭到破坏，您有足够的时间来更改密码。

这就是为什么现在最佳实践是通过加密通道交换密码并将加盐哈希存储在服务器上的原因，以及为什么存在其他实践......

今天我问自己同样的问题，因为我们在我们的网络中放置了一个蜜罐，它为我们提供了 Lansweeper SSH 密码（在所有 unix 机器上都可以使用......）。
因此，这是攻击者在企业网络中获取敏感密码的一种方式。

我当时想“...... WTF SSH 不使用质询响应？” . 然后我稍微说“......好吧，我想如果你使用挑战响应，那么哈希就是秘密，所以如果它被泄露，攻击者可以执行 pass-the-hash”。

和

我读到了SCRAM，它由服务器发送它的盐和 bcrypt 的轮数组成，客户端必须发送结果。
...这似乎与哈希是秘密的问题完全相同。所以我猜维基百科在这句话中犯了一个错误：
“由于没有存储密码本身，因此质询-响应算法通常必须使用密码的哈希值而不是密码本身作为秘密。在这种情况下，入侵者可以使用实际哈希而不是密码，这使得存储的哈希与实际密码一样敏感。SCRAM 是一种避免此问题的挑战-响应算法

编辑：我错了 SCRAM 确实允许存储无法重放的哈希，并使客户端在身份验证期间不泄露机密。
简化方案如下：
服务器存储 H(H(pass,salt)) （我们称之为 X）
客户端发送 R = H(X,nonce) XOR H(pass,salt)
服务器通过执行 H 来检查身份验证(H(X,nonce) XOR R) == X
这样，知道 X 不足以在另一台服务器上进行身份验证（不通过哈希），如果服务器是流氓服务器，R 不会泄露密码。

主要原因可能是，如果您不使用加密的 HTTPS 连接，无论您在客户端做什么，都可以轻松绕过。ManInTheMiddle 攻击者可以完全修改或删除 JavaScript。

因此，您唯一可以依靠的是加密的 HTTPS/SSL 连接。如果您没有对连接进行加密，那么所有客户端操作都毫无用处，如果您确实有 HTTPS 连接，则客户端操作对提高安全性几乎没有作用。

这通常适用于网站，另一种情况是用户在他的计算机上安装了客户端软件。安装客户端软件后，无需交换代码 (JavaScript)。

（自答题……）

我相信这是因为你不能在服务器端对密码进行加盐和哈希处理。

请注意，这里仍然需要加盐，因为如果服务器端密码被盗，那么即使在质询-响应场景中，它仍然可以用于登录。