请注意，THC-Hydra 统计数据是针对被描述为运行 SuSE Linux 7.2 的机器进行的。在SuSE / SuSE / SUSE / openSUSE Linux 发行版的历史中，这让我们回到了 2001 年中期，所以这个基准测试可能是在那个时代的机器上完成的。自那以后，技术得到了改进，计算速度也得到了提高。

典型的“弱远程 Web 服务”将使用 HTTP 基本身份验证，可能在 SSL 隧道内（即，这是 HTTPS，而不是 HTTP）。然后，每个密码猜测都需要以下内容：发送一个包含假定密码的 HTTP 标头（例如标头 200 个字节），然后获得错误响应（401 错误代码，标头的大小可能比攻击者选择；比如 1 kB 的标头）。由于 HTTP 支持keep-alive，TCP 连接（或 SSL/TLS 隧道）可以立即重用于另一次尝试；特别是，这意味着在存在 SSL 的情况下不会有明显的开销。每秒 1000 次尝试则需要大约 200 kB/s 的带宽到服务器，1 MB/s 的带宽；那是 10 Mbit/s 的带宽，甚至便宜的托管服务也能提供这么多。在本地网络上，100 MBits/s 或更高是常态。这里没有带宽问题。

当然，攻击者应该尝试并行化以避免延迟。在发送另一个请求之前无需等待服务器的回答。在这里，并行化意味着打开到目标服务器的一百个连接，并并行运行它们。如今，操作系统可以处理数千个打开的连接；一百不会饿死机器。

在服务器端，由于所有尝试都针对同一个用户，（散列的）密码将在 RAM 中（它通常存储在文件或数据库中，但 RAM 用作经常访问数据的缓存，并且在密码破解会话期间数据元素将被非常频繁地访问）。由于我们谈论的是弱远程 Web 服务，服务器将“按原样”存储密码或使用简单的哈希函数进行哈希处理，而不是像bcrypt这样的东西。重新散列每个传入的密码将使用可以忽略不计的 CPU（一台贫血的 PC 每秒可以计算数百万个散列，因此每秒 1,000 个散列是什么）。同样，HTTP 头解析也不会占用太多 CPU。

所以每秒 1000 次密码猜测似乎是一个非常可行的数字；实际上，大幅超过它应该不会太难。请注意上述讨论中的要点：

• 攻击者可以并行化，因为他有很多密码要尝试。
• 身份验证在处理传入请求的过程中很早就发生，因此请求的正常处理成本（对于 Web 服务提供的任何功能）不适用）。
• 在这种情况下，使用慢速散列函数（如 bcrypt）可能很有效。