你不能做出这样的假设。散列发生得非常快，即使是加盐的密码，并且使用安全的“慢”算法（甚至是一组链式算法）也会很快返回（对于人类）。对于每次登录尝试使用 10,000 次迭代的 PBKDF2 的粗略估计可以在一秒钟内处理 100,000 次尝试（仅查看散列时间时）。对您来说似乎“即时”的东西实际上对系统来说是相当长的时间。

还要记住，页面可能不必重新加载任何内容，它可能已经渲染了对话框，只是没有显示。或者页面可以使用持久连接而不是在发送凭据时创建新连接。两者都加快了响应时间。

这并不是说用户名/密码不正确的错误不能泄露信息。如果用户名无效（因此无需检查密码），某些站点会更快地返回错误消息。这可能导致攻击者枚举帐户用户名。

哈希估计：https ://stackoverflow.com/questions/11298184/about-how-fast-can-you-brute-force-pbkdf2

你的假设是错误的。加密哈希通常不会被设计为缓慢的。恰恰相反，MD5 和 SHA 系列密码散列函数等最广泛使用的散列在开发时明确考虑了速度。它们必须如此，因为它们可能用于散列大文件或为内部文件系统数据结构提供完整性检查，并且不应减慢读/写访问速度。加密散列函数的最大要求是不可能快速生成与给定散列匹配的输入文件，而不是它很慢。

话虽如此，有一个加密散列函数的子集被明确开发用作密码散列。这些确实被开发为（可配置地）缓慢以阻止蛮力攻击。两个例子是 PBKDF2 和 bcrypt。但这并不意味着密码存储只使用这些类型的加密哈希函数。

因此，您无法从快速拒绝中推断出密码哈希的存在。

我想这取决于具体情况。

如果您在拨号连接上运行 Windows 95 机器，连接到从 1990 年开始在重载的 Unix 机器上运行的 Web 服务，那么是的，我想需要一两秒钟才能返回结果。

然而，我们在 2016 年，CPU 运行在 GHz 范围内，互联网速度达到 MB/s。今天，散列到计算机是一项微不足道的壮举，只需要几分之一秒。对人类来说，这几乎是瞬间的。

如果我们使用 AJAX 并预渲染所说的“弹出”，我们将在最佳情况下立即看到结果。在 Facebook 或 Google 上尝试一下。您会立即看到结果。在 Raspberry Pi 上再试一次。你会看到同样的事情。

不，因为您的散列密码无论如何都只是纯文本。哈希是在您创建帐户时进行的，而不是每次登录时。如果有人使用与您相同的密码，那么他们也将拥有相同的哈希密码，这就是为什么许多网站需要复杂密码的原因。

这些纯文本密码的检索时间与创建它们的时间一样长，即使您使用的是较慢的方法，密码仍然会立即创建。

如此快速创建的密码如何安全？因为它是单向加密；这大大减少了服务器需要做的工作。