PBKDF2 和其他密钥拉伸算法意味着速度很慢，并且无论输入密码正确与否都需要相同的时间。

为了减少用户的计算负载和延迟，API 应通过登录凭据进行一次身份验证，并发出一个可撤销或有时间限制的会话令牌，该令牌通过简单的查找进行验证。

PBKDF2，或就此而言，任何密码散列算法，被设计为可调整的，因此它可能需要可变的时间，具体取决于所需的安全级别。假设使用相同的参数，无论密码是否正确，所花费的时间都是恒定的，因为在操作完成之前无法确定它是正确还是错误。

由于密码散列算法通常推荐的目标时间量是 100 毫秒，因此您可能会发现这样的速度会影响性能。但是，通常 API 不使用散列密码进行身份验证。向用户颁发某种令牌并让他们使用它进行身份验证更为常见。对于 Web 界面也是如此，我们称该令牌为会话 cookie。

如果您生成的令牌至少具有 128 位熵（256 位更好），或者您使用安全 MAC 或签名作为令牌，那么这通常是一种安全的身份验证方式。然后，您可以将随机令牌存储在数据库中，最好使用 HMAC-SHA-256 之类的东西（使用特定于您的应用程序的密钥）进行哈希处理，然后验证令牌的成本就会大大降低。或者，如果您使用安全的 MAC 或签名，您只需验证 MAC 或签名，然后检查令牌的 ID 是否仍然有效。

您永远不应该使用简单的哈希或 HMAC 存储密码或其他低熵机密，但如果您使用高熵机密（如从 CSPRNG 生成的令牌），这是安全的，因为暴力破解应该是不可能的。

请注意，PBKDF2 不再是推荐的密码散列算法。大多数密码学家更喜欢诸如 Argon2 或 scrypt 之类的内存硬算法，尽管不幸的是，政府标准的适应速度很慢。

当我们说 PBKDF2 很慢时，这是否意味着需要花费大量时间来散列密码并对其进行验证，因此服务对最终用户的响应速度不够？

它不会为您的 REST API 添加任何有意义的延迟。一次耗时 100 毫秒的计算不会被您的客户注意到，但对于试图对被盗数据库哈希执行数十亿次密码破解尝试的人来说，速度会非常慢。该算法所做的只是将密码破解的速度从每秒数十亿次尝试降低到数千次或更少。

还是只有在给出的密码无效而不是密码正确时，PBKDF2才慢？

不会。无论密码是否不正确，所用的时间都是一样的。实际上，必须先完成整个 PBKDF2 计算，然后系统才能确定密码是否正确。

PBKDF2 通常实现为 2048 次散列迭代，以减慢获得散列列表的密码破解者的速度。它的设计很慢。迭代次数是可配置的，但您是否会为了速度而降低它的安全性？

与线程的主题不同，是不是应该停止使用密码和会话令牌，而是使用 PKI 进行身份验证。对 Web 资源的 API 访问变得越来越普遍。HTTPS 已经支持使用客户端证书的 PKI 身份验证大约 20 年了。为什么不采用呢？