您引用的数字是关于每秒尝试密码的数量。由于这个密码散列函数是加盐的，攻击者一次不能攻击多个散列密码；同样，他们将无法构建和重用预先计算的表（“彩虹表”）。此外，该功能可配置多次迭代（“轮次”），以便您可以调整它以在您愿意在每次密码验证上花费的 CPU 数量和您想要的 CPU 数量之间进行权衡。攻击者花费在每次破解尝试上。如果你把轮数加倍，你会让每个人的工作变得更难，包括你在内。

默认的轮数（5000）意味着当时的普通计算机可以承受；最近的 PC 速度更快，增加机器的轮数将是一个好主意。

然而，攻击者可以使用特殊用途的硬件，特别是 GPU，来获得提升。升压取决于内部计算函数的方式。SHA-512 包含许多 64 位算术运算，GPU 对此并不完全满意，因此使用 GPU 获得的提升（与通用 CPU 相比，在相同的预算下）不如使用 GPU 获得的高SHA-256（仅使用 32 位操作）。但是，预计 GPU 在尝试破解密码方面将比 CPU 快几十倍。确切的数字很大程度上取决于所使用的 CPU 和 GPU，但是是的，100 倍的加速是可以想象的（不过我怀疑你低估了你的 CPU：它是多核的，此外，它具有一些与 SSE2 或 AVX 相关的固有并行计算能力寄存器）。

其他函数依赖于更多的内存访问操作，这使得 GPU 的任务更加困难，例如 bcrypt 和 scrypt。见这个答案对密码哈希大量的信息，并且是一个特定的治疗bcrypt的VS PBKDF2（这里讨论的目的，PBKDF2是相当类似Unix的crypt()功能，我们正在谈论）。

无论如何，正确的防御是不要有弱密码。如果你的密码在攻击者列表中是#11500，那么它很弱。一个合理的密码至少有 30 位熵，因此攻击者平均需要尝试 5亿次才能破解它。以每秒 11500 的速度，您还有几个小时的时间。再多一点记忆力，就可以得到40多位的熵，把这“几个小时”变成“几年”。

有关密码熵的讨论，请参阅此问题。另外，请记住，密码散列是第二道防线，只有在部分违规已经发生时才会生效：在 Unix 上下文中，/etc/shadow非 root 用户不应该读取，更不用说外部客户端了。所以不要太担心密码散列，并专注于不允许 SQL 注入或缓冲区溢出。

数字是正确的。

这里的要点是 MD5 和 SHA 都意味着要快。它们旨在用于需要尽可能快的内容校验和。现代计算机甚至有自己的指令来在硬件上计算这些。

MD5 和 SHA512 之间最大的区别在于密钥空间，与 MD5 相比，SHA512 中哈希冲突的可能性要小得多。请参阅MD5 碰撞漏洞。

它们的密钥空间在密码的安全性方面并没有起到特别大的作用。

为了加密安全，您应该使用像 scrypt 这样的慢速函数。

并回答您的另一个问题：

或者这是否意味着平均每秒可以破解 11,500 个用户帐户？现在那将是真正令人印象深刻的。

那么“破解”取决于密码以及是否使用盐。

这个数字的意思是“这个东西每秒可以计算多少个哈希值”。

所以如果你没有盐并且破解者发现明文'foobar'的5000轮散列是'abc123def'，它可以检查这个散列是否在/etc/shadow文件中找到。没有盐的问题是两个不同的用户可能有相同的密码，并且他们都会同时被发现，因为他们的哈希值是相同的。

当您使用加盐密码时，攻击者不能使用预先计算的彩虹表，而是需要使用他们自己的盐分别攻击每个用户。

我相信在这种情况下 c/s 代表计算/秒。当使用盐时，您需要重新计算每个哈希的所有内容。如果不使用盐，您可以在一次运行中计算所有内容。

这是最近在不同 GPU 上进行基准测试的表格。如您所见，这些数字同样高（我知道 SHA-512 不在其中，但它应该给您一个指示）。这些是每个散列计算的散列数量。如果添加轮次，则需要将每一轮都算作一次哈希计算。越来越多的人转向 Bcrypt 和 Scrypt，它们被设计为在 GPU 上运行非常不友好，因为它们需要大量内存。Scrypt 甚至比 Bcrypt 更好，但我想在这里向您推荐这个答案有没有安全专家推荐 bcrypt 用于密码存储？

现在，该列表中最快的 GPU 每秒可以计算大约 2 656 000 000 个哈希（不是破解，计算！）。一个普通的 ASCII 密码可以有 95 个字符（ASCII 只有 95 个可打印字符）。为了计算可能的字符数量并假设密码通常约为 8 个字符，我们得出95^8 = 6.6 quadrillion( 6 634 204 312 890 625) 种可能性。要破解所有这些，如果他们使用 5000 发子弹，我们将得出：2 656 000 000/5000 = 531 200 c/s. 这比您的示例要少得多，但是让我们假设他们正在运行一个 GPU 农场，并且他们实际上可以11 500 000 c/s以 5000 轮计算。我们会在6.6 quadrillion/11 500 000 = 573 913 043几秒钟内计算所有这些哈希值。

一小时有 3600 秒，一天有 24 小时，所以：573 913 043 seconds / (24 * 3600) = 6642 days. 破解这些密码仍然需要 18 年（！），而我们只是在考虑没有那么多特殊字符的 ASCII。加入盐，事情就会变得更慢。使密码长一个字符，它会慢 100 倍。将其延长 12 个字符（我始终建议将其用作 root 等管理帐户的最低限度），这对您来说是 540 六分之一。所以即使

我将通过指出哈希和盐应该在一个由操作系统很好地保护的文件中来回答这个问题。

一个合理的安全策略应该将传入的身份验证请求限制在每天不允许超过 100 次密码输入尝试的速率。

如果攻击者拥有您的/etc/shadow内容，则几乎必须担心更大的事情。这通常是一个非常人为的情况。

这可能就是为什么没有太多人过度关注配置最大程度防弹密码散列方案的原因：不要透露散列和盐。如果这样做有任何风险，请中止。即使对于那些旧的 MD5 东西也应该可以正常工作；只是这样，哈希，如果被泄露，就会更有启发性。

这一点我可能错了，这非常重要（因为在加密中，所有位都必须正常运行，否则它们都是无用的），我只是认为 SSL 之类的安全性在优先级列表中要高一些。

也就是说，我现实生活中的例子是，由于安装程序启动媒体的限制，我正在通过 HTTP 分发我的机器的初始 root 密码。为什么我不以更安全的方式来做呢？因为我就是那样疯狂。

解决方案？想出一个该死的长密码，在机器上线后更改它。这将成功攻击的机会减少到有效地为零。

实际上，我看不到一种直接的方法可以通过使用基于例如的加密来绕过这个问题scrypt，这种方法的攻击速度非常慢：必须设置一个 root 密码才能获得访问权限，以便能够输入scrypt 加密密码。因此，在操作系统附带支持它的加密模块之前，它可能是不可能的。

我确实看到了让新机器scrypt自行编译并在此基础上自动设置单独的身份验证层的可能性。这样的努力肯定会有很多问题。

（但是，我确实打算打包一个用 SSH 私钥加密的密钥，scrypt这样它在比密码哈希值更长的时间内是安全的）