首先，请确保您阅读了对“客户端密码散列”问题的答案，特别注意最后一段。

另外，请意识到与良好的服务器端代码相比，PBKDF2 的客户端 javascript 将非常慢。至少尝试找到一个使用 HMAC-SHA-512 作为基础的 PBKDF2 实现。

也就是说，如果您想让用户放心，那很好；请执行下列操作：

• 已知的“高”迭代计数的客户端 PBKDF2 散列。
  • 如果允许用户自己选择迭代次数，则加倍积分！
  • 我之所以加引号，是因为我怀疑您的 javascript 代码是否足够快，可以在您获得足够多的用户群接受的时间内完成数万或数十万次迭代，尤其是在更便宜的移动设备上。
  • 用户名和密码的良好哈希值作为盐并不是很好，但如果您的代码将用户名填充到最大可能长度并将其放在首位会更好。
    • 这样，“user1”和“password”就不会和“user”和“1password”做同样的盐！
    • 当然，密码没有最大长度，除非是由您的后端软件引起的；例如，SQL Server 在“效率较低”的字符串工作上最多有 8000 个字节。
• 将该哈希本身发送到服务器
  • 然后它会生成一个 12-16 字节的加密随机盐
  • 然后使用具有更高迭代次数的 PBKDF2 对传入的哈希进行哈希处理
    • 再次希望 HMAC-SHA-512 用于 64 位操作，以减少离线 GPU 攻击的比例优势。
    • 因为随后获得您泄露的密码数据库的人仍然必须对密码散列函数进行攻击才能登录，而不是简单地发送他们窃取的客户端生成的散列并使其按原样被接受。

尤其要记住 PBKDF2 密码散列，永远不要要求输出大小大于本机基本散列的输出大小。如果您真的非常关心存储，较小的就可以了；例如，仅请求 PBKDF2-HMAC-SHA-512 的本机 64 字节输出的 32 字节。

• SHA-1 20 字节
• SHA-256 32 字节
• SHA-512 为 64 字节