我正在尝试在我的网站上实施 2FA，但无法弄清楚如何生成然后安全地存储恢复令牌。
从我所见，如果由于某种原因您无法进行 MFA（可能丢失了您的设备），您可以使用恢复令牌作为您的第二个因素。我担心安全地存储它们。在 Github 等网站上，您可以随时查看您的恢复令牌，这意味着它们不会经过哈希处理和存储。这似乎不太安全。在搜索这方面的指南和最佳实践时，我的 google-fu 似乎已经抛弃了我。
PS - 我正在寻找有关如何将恢复令牌的生成和存储实现为服务的指南。
生成并安全存储 MFA/2FA 恢复令牌
信息安全
多因素
2021-08-19 05:32:20
2个回答
备份密钥基本上等同于您的密码。您正在寻找的准则与存储您的个人密码的准则相同。不会有不同的指导方针。
密码和 MFA 代码之间的一个细微差别是，您往往很少需要这些代码（可能只需要一次），并且当出现问题时。这意味着您需要遵循业务中“灾难恢复”或“业务连续性”的密码管理指南。
这通常意味着打印/写出它们并安全地存储物理介质（锁定、密封、以某种方式混淆，以防有人偶然发现它们），并且在出现问题时您可以访问它。这种方法的细节高度依赖于“什么可能出错”的范围。就个人而言，我遇到了地震/洪水场景，我丢失了设备和桌面，需要登录新的/奇怪的设备。
另一个答案是正确的，应该对恢复代码进行哈希处理。NIST 在800-63b的第 5.1.2 节“查找秘密”中发布了这方面的指南，并指出：
...查找机密的一个常见应用是使用订阅者存储的“恢复密钥”，以在另一个身份验证器丢失或发生故障时使用。...
验证者应以能够抵抗离线攻击的形式存储查找秘密。具有至少 112 位熵的查找秘密应使用第 5.1.1.2 节中所述的经批准的单向函数进行散列。熵少于 112 位的查找秘密应使用合适的单向密钥推导函数进行加盐和散列，也在第 5.1.1.2 节中描述。盐值的长度应至少为 32 位，并且可以任意选择，以最大程度地减少存储的散列之间的盐值冲突。盐值和生成的哈希都应为每个查找秘密存储。
对于熵少于 64 位的查找秘密，验证者应实施速率限制机制，有效限制可在 5.2.2 节中描述的订户帐户上进行的失败身份验证尝试的次数。
尽管如此，一些著名的网站（包括 GitHub、Google 和 Facebook）还是以明文或可逆加密的形式存储它们，允许用户随时查看它们。