TL;DR：由于 Windows 在非 Kerberos（非 Active Directory）场景中对网络用户进行身份验证的方式，密码散列的工作方式与验证网络用户的密码一样。

长版：有两种使用密码对某人进行身份验证的传统方法：

• 客户端将密码发送到服务器（传统上是明文，尽管较新的协议使用加密）。服务器获取密码，对其进行哈希处理，并将其与存储的密码哈希进行比较。如果哈希匹配，则假定客户端具有正确的密码并被视为已通过身份验证。
• Challenge-response：服务器生成一个挑战（随机字节序列）并发送给客户端。客户端接受挑战，将其与客户端的密码组合，对结果进行哈希处理，并将哈希发送到服务器。同时，服务器接受挑战，将其与存储的密码结合起来，并对结果进行哈希处理。如果两个哈希值匹配，则客户端被视为经过身份验证。

请注意，在质询-响应方案下，密码永远不会真正发送到服务器（这很好），但服务器需要知道密码（这很糟糕）。第一种方法是传统的 Unix 方法；二是传统的Windows方式。

为了减轻质询-响应的“服务器需要知道密码”的缺点，许多质询-响应实现使用密码的哈希值。换句话说，实现不是比较 的哈希，而是(challenge + password)比较 的哈希(challenge + hashed password)。但是，在这种情况下，哈希密码仍然是访问服务所需的全部内容（因为恶意客户端(challenge + hashed password)即使不知道明文密码也可以发送哈希值）。因此，在质询-响应方案下对密码进行散列处理使得获得可能用于攻击其他服务的明文密码变得更加困难，但在服务本身的安全性方面并没有什么区别。

进一步阅读和参考：

• https://www.toshellandback.com/2017/02/11/psexec/

  一旦获得哈希，破解它们以发现明文密码可能是一项漫长而艰巨的任务（假设密码不会屈服于单词列表或彩虹表攻击）。对我们来说幸运的是，Windows 在许多情况下会很乐意接受 NTLM 哈希值，例如通过其 IP 地址（与主机名）访问网络资源或连接到未加入域的设备。唯一不会交换哈希的情况是在 Kerberos 专有环境中请求网络资源时，但这种类型的实施很少见，并且对于许多组织来说实施起来可能会有问题。

• https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication

  许多（但不是全部）质询-响应算法……要求客户端和服务器都有一个共享的秘密。由于不存储密码本身，因此质询-响应算法通常必须使用密码的哈希值而不是密码本身作为密码。在这种情况下，入侵者可以使用实际的哈希而不是密码，这使得存储的哈希与实际密码一样敏感。

• https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html#id2588057

  UNIX 方案通常在登录时通过网络发送明文密码。这很糟糕。SMB 加密方案从不通过网络发送明文密码，但它确实将 16 字节的散列值存储在磁盘上。这也很糟糕。为什么？因为 16 字节散列值是“密码等价物”。您无法从中获取用户的密码，但它们可能被用于修改后的客户端以获取对服务器的访问权限。这需要代表攻击者的大量技术知识，但完全有可能。因此，您应该将存储在您使用的任何 passdb 后端（smbpasswd 文件、LDAP）中的数据视为包含所有用户的明文密码。

获取哈希与获取实际密码不同

但是，对于典型用户来说，它与获取实际密码一样好。此条目介绍的是电力公司的工人。您认为您的普通电力公司技术人员在工作时是否有一个 9 字完全随机的 diceware 短语作为他们的登录密码？最有可能的是“MyDogFido！7”（因为他们已经拥有 7 次密码更改的密码）。他们只需要破解一个哈希就可以在系统中建立一个滩头阵地；有足够的员工，如果他们能得到所有员工的哈希值，我相信他们至少会得到一个。