2019年双因素认证最佳实践指南

news/2025/9/18 17:25:36/文章来源:https://www.cnblogs.com/qife122/p/19099235

2019年正确实现双因素认证 - Trail of Bits博客

自3月起，Trail of Bits一直与Python软件基金会合作，为Warehouse（PyPI的代码库）添加双因素认证（2FA）。截至目前，PyPI成员可以启用基于时间的OTP（TOTP）和WebAuthn（目前处于测试阶段）。如果您在PyPI上拥有账户，请在继续阅读之前启用您偏好的2FA方法！

2018年和2019年是双因素认证的重要年份：

W3C和FIDO于3月最终确定了Level 1 WebAuthn规范。Chrome和Firefox已经对其提供了成熟支持，Safiri预计也会跟进。
即将发布的Android版本将允许用户将手机用作安全密钥，iOS预计也会这样做。
CTAP2标准的进展持续进行。虽然WebAuthn不需要CTAP2，但未来的WebAuthn设备将受益于其传输和认证器配置改进。
主要网站已开始不鼓励使用SMS和语音代码，这些作为第二因素已经完全失效。Google现在允许G-Suite管理员强制执行无SMS的2FA，防止用户为其2FA方法添加薄弱环节。

总而言之，现在是为您的服务添加2FA的最佳时机。继续阅读以了解如何正确实施。

什么是2FA，什么不是

在讨论实施双因素认证的正确决策之前，理解第二因素应该是什么和不应该是什么至关重要。

特别是：

第二因素方法不应该是可知的。第二因素方法是用户拥有或是什么，而不是用户知道什么。
第二因素方法不应替代用户的第一因素（通常是密码）。因为它们是用户拥有或是什么，所以它们是身份证明。WebAuthn是此规则的部分例外：由于其更强的保证，它可以作为单一因素。
第二因素方法可按安全性排序。特别是，WebAuthn总是优于TOTP，因此应首先提示已启用两者的用户使用WebAuthn。不要让用户默认使用安全性较低的第二因素。如果出于遗留原因支持SMS作为第二因素，请告知用户一旦添加了更好的方法就可以移除它。
2FA实现不应在第一因素之前请求用户的第二因素。这对于TOTP来说无论如何都不可行，但您可能会尝试使用WebAuthn凭据的ID或公钥。这本身不会引入安全风险，但不一致的排序只会混淆已经难以理解安全密钥在认证中作用的用户。
恢复代码应可用，并且应为选择退出的用户提供足够警告，这些用户更喜欢其账户在失败时完全不可用。恢复代码不是第二因素——它们绕过了2FA方案。然而，用户不理解2FA（见下文），如果没有直接的恢复方法，他们会因挫败感而禁用它。当安全存储时，恢复代码代表了可用性和2FA方案健全性之间的可接受折衷。

您的用户不理解2FA，并会尝试破坏它

用户，即使是技术极客（如普通的PyPI包维护者），也不理解2FA或其约束。他们会在不同程度上：

尝试行为	风险	补救措施
截屏TOTP二维码并留在下载文件夹中	TOTP密钥暴露	文档：警告用户不要保存二维码
使用相同二维码配置多个TOTP应用	对第二因素是什么/在哪里理解不足	文档：告知用户仅配置一个设备
使用允许以未加密文本导出代码的TOTP应用	TOTP密钥暴露；不安全的密钥管理	文档：建议使用不支持未加密导出的TOTP应用
使用损坏的TOTP应用或不尊重TOTP参数的应用	不正确的TOTP代码生成；应用中混淆的TOTP标签	几乎没有：几乎所有TOTP应用都忽略或对配置施加额外约束。使用默认配置参数！
用错误应用扫描TOTP二维码	丢失第二因素；无法登录	要求在接受配置请求前输入TOTP代码
尝试手动输入配置URI或密钥并出错	丢失第二因素；无法登录	同上；需要TOTP代码完成配置
错误标记TOTP登录并混淆	错误标记的第二因素；无法登录	提供otpauth支持的所有用户名和发行者名字段。不鼓励用户使用仅支持服务白名单或需要手动标记的TOTP应用
在您的服务之前从应用中删除TOTP密钥	账户锁定	文档：警告用户不要这样做，并推荐提供类似警告的TOTP应用
将恢复代码保存到桌面文本文件	第二因素绕过	使恢复代码选择加入，并告知用户仅保存恢复代码的打印副本
混淆不同服务的恢复代码	丢失绕过；无法登录	在恢复代码前添加站点名称或其他区分标识符
完全忽略第二因素，仅使用恢复代码	非真正的2FA	跟踪恢复代码使用并警告重复违规者
尝试使用旧的RSA SecurID、奇怪的企业HOTP令牌或pre-U2F密钥	WebAuthn不支持	在配置失败时提供明确错误。大多数浏览器应对pre-U2F密钥执行此操作
混淆硬件密钥	错误标记的第二因素；无法登录	让用户能够在您的服务上以人性化名称标记其注册密钥，并鼓励他们物理标记
在未取消配置的情况下赠送或转售硬件密钥	第二因素泄露	文档：警告用户不要这样做。为了更积极的安全，定期要求他们断言其每个WebAuthn凭据

技术用户可能更糟：在撰写本文时，一位熟人讲述了使用Twilio和通知推送服务绕过其大学基于SMS的2FA的故事。

这些场景中的许多部分不可避免，并且并非所有场景都从根本上削弱或威胁削弱您的2FA设置的健全性。然而，您应该了解每一个场景，并尽可能寻求用户验证您的方案。

WebAuthn和TOTP是您唯一需要的

您不需要SMS或语音代码。如果您目前出于遗留原因支持SMS或语音代码，那么您应该：

防止新用户启用它们，
告知当前用户移除它们并切换到WebAuthn或TOTP，以及
对仍启用SMS和/或语音代码的用户执行额外日志记录和警报。

偏执？是的。但如果您持有任何加密货币，您可能应该偏执。

过度？也许。SIM端口攻击仍然相对不常见（且有针对性），尽管几乎不需要技术技能。通过SMS或语音代码进行2FA仍然比什么都没有好。Google自己的研究表明，仅SMS就能防止几乎所有非针对性钓鱼攻击。针对性攻击的数字更黯淡：近四分之一的针对性攻击对仅基于SMS的2FA用户成功。

担心除了SMS之外的其他方法不实用和/或成本高？不必担心。有大量免费的TOTP应用适用于iOS和Android。在WebAuthn方面，Google将以50美元的价格向您出售包含两个安全密钥的套件。您甚至可以购买一个完全开源的密钥，该密钥可与WebAuthn配合使用，价格为25美元！最重要的是：TOTP不如硬件密钥好，这不是继续允许SMS或语音代码的借口。

对比TOTP和WebAuthn

TOTP和WebAuthn都是为您的服务添加2FA的可靠选择，如果有机会，您应该同时支持两者。以下是一些考虑因素：

TOTP是对称且简单的，WebAuthn是非对称且复杂的

TOTP是一种对称加密方案，意味着客户端和服务器共享一个密钥。这加上TOTP相对简单的代码生成过程，使其易于实现，但会导致一些陷阱：

由于客户端需要存储对称密钥，TOTP的安全性仅与包含应用或设备一样安全。如果恶意程序可以提取用户的TOTP密钥，则它们可以在用户不知情的情况下生成任意数量的有效TOTP代码。
由于TOTP中客户端和服务器之间共享的唯一状态是初始密钥和后续生成的代码，TOTP缺乏设备身份的概念。因此，信息错误的用户可以使用相同密钥配置多个设备，增加其攻击面。
TOTP不提供固有的重放保护。服务可能通过拒绝接受有效代码多次来防止重放，但这可能会困扰在TOTP窗口内多次登录的合法用户。
可能可暴力破解。大多数服务使用6或8位TOTP代码，并提供扩展的验证窗口以适应行动不便的用户（和时钟漂移），使在线暴力破解刚刚处于可行性边缘。解决方案：限制登录尝试速率。

以上所有因素结合使TOTP代码成为理想的钓鱼目标。私人和国家团体都成功使用假登录表单和其他技术成功欺骗用户共享其TOTP代码。

相比之下，WebAuthn使用非对称公钥密码学：客户端在从服务器接收选项列表后生成密钥对，将公钥部分发送到服务器用于验证目的，并安全存储私钥部分用于认证期间的签名操作。这种设计导致 substantially更复杂的证明模型，但产生许多好处：

设备身份：WebAuthn设备由其凭据ID标识，通常与人性化标签配对用于用户管理目的。WebAuthn的身份概念使得支持每个用户多个安全密钥变得容易——不要人为地将用户限制为每个账户单个WebAuthn密钥！
反重放和反克隆保护：设备注册和断言方法包括认证方生成的随机挑战，行为良好的WebAuthn设备在每次断言后发送更新的签名计数器。
来源和安全上下文保证：WebAuthn在设备注册和证明期间包括来源信息，并仅允许在安全上下文内进行交易，防止常见钓鱼向量。

TOTP是免费的，WebAuthn（目前大部分）不是

如上所述，有许多免费的TOTP应用，适用于用户将使用的几乎所有平台。几乎所有这些都支持Google的otpauth URI“标准”，尽管完整度/正确性程度不同。

相比之下，大多数WebAuthn的潜在用户需要购买安全密钥。各种硬件密钥标准之间的关系令人困惑（并且可能占据整个单独的博客文章），但大多数U2F密钥应该是WebAuthn兼容的。然而，WebAuthn不仅限于安全密钥：如前所述，Google正在努力使其移动设备充当WebAuthn兼容的第二因素，我们希望Apple也在做同样的事情。一旦发生这种情况，许多用户将能够在没有额外购买的情况下切换到WebAuthn。