SRP 中的密码实际上是（可能）低熵的共享秘密。它可以是人类用户理解的“密码”，也可以是从密码确定性派生的任何内容。在您的情况下，是的，使用密码散列函数（例如 PBKDF2）是一种有效的方法。它有以下警告：

• PBKDF2 与 bcrypt 和其他良好的密码散列函数一样，需要salt。盐很重要。没有盐，攻击者可以在很大程度上优化攻击；也就是说，他只需要为一个用户支付 PBKDF2 步骤的费用（如果他有几个存储的哈希值供多个用户破解）。这里的要点是客户端和服务器必须为给定用户使用相同的盐，因此客户端必须以某种方式知道该盐。但是盐仍然必须特定于每个用户（并且每当用户更改密码时也会更改），因此您不能简单地在客户端代码中对其进行硬编码。

  因此，您需要将每个用户的 salt 存储在服务器上，并将其作为初始身份验证步骤传送给客户端。在 SRP 中，客户端首先发送包含用户名 ( I ) 和不依赖于密码 ( A ) 的值的消息。服务器使用特定于用户的盐 ( s ) 和另一条消息 ( B ) 进行响应。您还应该在该服务器到客户端消息中发送 PBKDF2 所需的额外盐。

  或者，您可以将 SRP 中的散列步骤替换为 PBKDF2，但这涉及修改协议和实现库，这可能不是一个好主意。添加额外的 PBKDF2 步骤更简单，也更安全。

  重用与 SRP 指定的盐（协议规范中称为s的盐）相同的盐是很诱人的。虽然这在这里看起来是加密安全的（两种盐的用法有点“分离”，它们之间的所有 PBKDF2），但这种事情被认为是一个微妙的问题，而且，再一次，有一个额外的、独立的盐是安全、谨慎的方法。

• PBKDF2 采用多次迭代来减缓攻击者的速度。但它也会减慢普通用户的速度，因此您无法将迭代次数提高到您希望的程度。考虑到所涉及计算机的负载和计算能力，以及用户耐心的限制，您应该设置尽可能高的值。

  在与 SRP 集成的情况下，与任何其他PAKE协议一样，密码散列的主要成本在客户端。因此，适当的迭代计数取决于客户端计算机。如果您有多个客户端，那么您必须调整到仍然应该能够连接的最不强大的计算机。这一点对于使用 JavaScript 的基于 Web 的客户端尤其重要，因为 JavaScript 对于原始计算非常微弱，严重限制了您可以容忍的迭代次数。在您的情况下，客户端的代码使用 C 库，因此您可以拥有一些客户端肌肉，但是由于您正在使用“旧游戏”，因此您必须考虑客户端可能是“旧机器”，可能是“长辈 机器”。有一些变态仍然在护理一些 i486 计算机。

• 您可以考虑使用 bcrypt 代替 PBKDF2；bcrypt可以说对使用 GPU 的攻击者更强大。