有很多方法：

• SQL注入
• 泄露的备份
• 心怀不满的员工泄露他们
• 允许代码执行的任何类型的服务器破坏。

正如你所看到的，这可能发生的方式有很多种——正如phihag在评论中提到的那样，超过一半的OWASP 前 10 名可能导致散列泄露——因此它们不能轻易地在帖子中列出。

这并不意味着黑客获取哈希是不可避免的，但您仍然应该使用良好的哈希算法来保护自己和您的用户，以防万一。由于备份可能会丢失或您的服务器在您没有注意到的情况下被黑客入侵，因此拥有正确散列的密码应该是唯一能让您在晚上睡觉的东西。这种策略被称为“纵深防御”，或者只是“做最坏的打算”。

有很多方法。这里有一些我能想到的。现在我的语法可能有点错误，因为我现在没有费心去测试它，但总的来说，这些都是你为了获取数据而要做的事情。

请注意，对于以下漏洞，我不一定提供窃取哈希的示例（SQLi 除外），而是提供漏洞如何工作的示例。攻击者将使用以下漏洞进一步破坏系统。

1. SQL注入

   例子：
   a OR 1=1'; exec sp_msforeachtable "SELECT * FROM ?";--

   你也可以使用sp_msforeachdb，像这样：

   a'; exec sp_msforeachdb 'USE ?;exec sp_msforeachTable "SELECT * FROM !","!"';--

   --可以注释掉可能会干扰您的注入的部分 SQL 语句。这些只是非常基本的例子。这实际上取决于查询的格式。

2. 操作系统注入。; cat /etc/passwd; rm -rf /*
3. LDAP 注入。*,(cn = *)(|(password =*))

4. 不安全的直接对象引用导致本地/远程文件包含漏洞。

   /etc/passwd%00 （注意：密码当然不会存储在这里；当人们重复使用密码时找到有效的用户名是这里的关键，或者使用用户名来帮助提升权限）

   %00是一个“空终止符”，用于避免后面出现任何内容，因此您不要尝试包含不存在的内容，例如：/etc/passwd.txt. 这也可能是\000, \x00, \z, \u0000, \0, 或\00取决于您使用的语言。

5. 入侵有权访问数据库的开发人员/用户。
6. 通过其他方式利用数据库服务器或 Web 服务器。

Mark Buffalo 的一项补充：
7. 中间人攻击。观看未加密的流量通常可以揭示密码哈希。在传递哈希的情况下，系统将信任哈希和密码，并让攻击者简单地复制哈希而不破解它。

唯一真正安全的计算机是与互联网隔离、关闭、拔掉电源、埋在地下 100 英尺的掩体中、唯一入口处有武装警卫的计算机。即便如此，我也会每隔一段时间检查一次。

散列密码是所谓的“深度安全”的一部分。您是对的，在理想的世界中，您不会犯任何错误，从而使攻击者可以访问该数据，因此从理论上讲，它们是明文密码还是散列都无关紧要。在现实世界中，入侵确实会发生，而且很难预测它们将如何以及在何处发生。深度安全背后的想法是，从理论上讲，即使攻击者以某种方式破坏了您的系统，您也已努力减轻损害。

在现实世界中，自然需要定期访问哈希。每次用户登录时，您都需要能够访问它们。因此，无论什么应用程序进行身份验证，它们几乎总是可以访问的。如果有人破坏了您的应用程序，他们可能能够读取他们不应该能够读取的数据。

这些攻击发生的方式是无穷无尽的。如果您未能清理输入，您可能会受到 SQL 注入攻击。您可能会出现缓冲区溢出，从而使攻击者能够运行自己的代码。您可能会遇到权限错误，意外地使人们不应该读取的文件。由于您的备份服务处理不当，攻击者可能会得到您的其中一个备份磁带！

所有这些攻击都使攻击者能够在您的计算机上立足，但它们并不总是导致完全破坏。您可能已经对您的 SQL 服务器进行了 chroot，因此 SQL 服务器进程实际上无法看到计算机的整个其余部分。但是，在这种情况下，用户需要的登录信息必须在 SQL Server 的范围内，否则就没有任何价值。因此，登录信息通常会在其他更邪恶的危害发生之前受到危害。

通过散列密码，您降低了它们的价值。哈希对于登录目的没有用。他们需要拥有哈希到该值的密码。他们可能或可能无法承担破坏哈希的成本。在最好的情况下，您从一开始就不需要担心这一点，但是如果您订阅深度安全方法，您可以确保即使成功的入侵也不会损害您的所有数据。