O3.02.1Threat-dependent authenticator strength设计研究

不同因素的安全强度差异很大

别名: 认证器强度 · 抗钓鱼认证 · authenticator assurance

概念解释

随威胁而变的认证器强度(threat-dependent authenticator strength)指“第二因素”不是统一安全等级。短信、语音、手输一次性码、推送确认、硬件密钥和绑定站点的加密认证器,对实时钓鱼、号码转移、设备窃取、恶意软件、提示轰炸和验证端泄露的抵抗能力不同;仅标注“已开启 2FA”会掩盖这些差异。

机制

攻击者瞄准的是协议中的可转移信息和薄弱通道。用户能读出并重新输入的码通常也能被假页面实时转交;只需点击批准的推送可能在反复打扰下被误准。把加密响应绑定到正确验证方,可减少秘密被转送到假站点的空间,但安全仍取决于密钥保护、设备解锁、绑定和恢复过程。因此,因素数量只是结构描述,不能代替威胁模型。

怎么研究

先列出资产、攻击者能力与认证流程,再对每种可选认证器做协议级和人因测试。授权红队可模拟代理钓鱼、号码转移信号、被盗但锁定的设备、推送轰炸和恶意恢复;记录凭据是否可转移、用户是否能辨认交易、攻击成功与误拒,而不是只比较登录时间。测试环境不得诱骗真实用户交出生产凭据。

边界

较弱的第二因素在某些低风险或受限环境中仍可能显著优于只有密码,并可作为迁移或覆盖渠道。所谓抗钓鱼也不是抗所有攻击:已解锁端点、会话窃取、恶意应用和错误恢复仍可能绕过它。具体允许哪些认证器应随账户价值、用户可达性、设备生态和适用标准决定,不能用单一全球排序替代情境判断。

怎么落地

  • 为每种认证器记录能抵抗与不能抵抗的威胁,不只记录“一个额外因素”。
  • 对高影响动作优先提供并引导采用与验证方绑定的加密认证器,同时保留经过风险控制的可达替代方案。
  • 推送确认显示发起设备、地点或交易摘要并限速;避免仅凭无上下文的“允许”按钮完成认证。
  • 在设置页用“抗实时钓鱼、依赖电话网络、需要实体设备”等后果语言解释差异,并持续监测降级和绕过路径。

延伸

  • 同组O3.02.2 恢复路径的安全下限 · O3.02.3 第二因素丢失处置
  • 相邻O3.10 多因素认证的可用性 · O3.04 钓鱼识别线索
  • 站内检索phishing-resistant authentication · authenticator assurance · MFA threat model

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/O3.02.1