对于密码散列，我们在 BCrypt 和 PBKDF2 之间犹豫不决。在许多论坛和博客中，人们会说“在他们的特别出版物 SP 800-132 NIST 中基本上建议使用 PBKDF2 进行密码散列”。
对于我们的客户来说，这可能是一个非常重要的论据（他们喜欢标准）。但是我仍然无法以纯文本形式阅读此建议......所以我不能舒服地声称它。简而言之，NIST 或多或少说：
派生的密钥材料称为主密钥 (MK)，表示为 mk。MK 用于 1) 生成一个或多个数据保护密钥 (DPK) 以保护数据，或 2) 生成中间密钥以保护一个或多个现有 DPK，或使用经批准的密钥派生函数 (KDF) 从 MK 生成) 如 [2] 中所定义。MK 不得用于其他目的。
是否有这样的建议或者这只是一个神话？
建议将 PBKDF2 用作从密码生成加密密钥的算法，而不是用于对密码进行哈希处理以进行安全存储以进行身份验证。（我相信你也在加盐？）所以答案是否定的，对于你的用例，没有这样的建议。这并不意味着它不适合，但没有 NIST 推荐可以引用。
我想你正在寻找这个：
验证者应以能够抵抗离线攻击的形式存储记忆的秘密。秘密应使用经过批准的散列函数（如[SP800-132]中所述的 PBKDF2）使用盐值进行散列。盐值应是一个 32 位（或更长）的随机值，由经批准的随机位生成器生成，并与散列结果一起存储。散列函数至少应执行 10,000 次迭代。密钥散列函数（例如，HMAC），其密钥与散列验证器分开存储（例如，在硬件安全模块中）应该用于进一步抵抗针对存储的散列验证器的字典攻击。
虽然 NIST SP 800-132 并不是专门针对密码散列，尤其是与用于身份验证的密码无关，但强烈建议使用 PBKDF2，尤其是因为它具有蛮力抵抗力。
然而，即将到来的NIST SP 800-63B草案（数字身份指南认证和生命周期管理）明确提到了PBKDF2，但它也要求基于HMAC的胡椒：
验证者应以能够抵抗离线攻击的形式存储记忆的秘密。秘密应使用经过批准的哈希函数（如 [SP 800-132] 中所述的 PBKDF2）使用盐值进行哈希处理。盐值应是一个 32 位或更长的随机值，由经批准的随机位生成器生成并与散列结果一起存储。散列函数至少应执行 10,000 次迭代。密钥散列函数（例如，HMAC [FIPS1981]），其密钥与散列验证器分开存储（例如，在硬件安全模块中）应该用于进一步抵抗字典对存储的散列验证器的攻击。
关于这一点有很多争论，但无论如何它要求“批准的哈希函数”排除scrypt（部分是因为它故意使用 PBKDF2 步骤）和bcrypt。我喜欢它要求单独储存胡椒的事实。这就是我重新尝试定义通用PBKDF2格式的原因：https ://github.com/ecki/habibi-passwordhash