抗钓鱼多因素认证的技术边界与纵深防御定位

摘要： 多因素认证长期以来被视为防范账号接管的核心手段，但其有效性取决于所采用的具体因素类型。基于短信、邮箱验证码、应用口令与推送确认等方式虽可抵御弱口令风险，却仍能被实时中转的钓鱼代理所利用。2026 年，围绕 Salesforce 平台抗钓鱼多因素认证的讨论显著增多：一方面，安全社区与第三方来源报告，Salesforce 正要求系统管理员等高权限用户改用绑定站点地址的安全密钥、通行密钥或设备内置认证器；另一方面，谷歌威胁情报组披露的 UNC6040 语音钓鱼事件则表明，此类认证并不能阻止已登录用户批准恶意连接应用。本文以该事件为切入点，分析抗钓鱼认证的非对称密钥原理、适用范围的划定逻辑及其能力边界，并在此基础上讨论其在纵深防御体系中的准确定位。研究认为，抗钓鱼多因素认证的价值在于将身份认证环节与钓鱼代理隔离，但其防护止步于 “认证” 本身，对认证之后的授权滥用、会话窃取与账户恢复绕过并无直接作用；唯有将其与连接应用管控、最小权限、日志监测与人因培训协同部署，方能构成完整的防护闭环。

关键词： 抗钓鱼认证；WebAuthn；FIDO2；语音钓鱼；纵深防御

1 引言：一种无法 “卸载” 的登录功能

在网络安全领域，一个看似矛盾的现象是：某些引发用户搜索与咨询的 “威胁”，其本质并非恶意程序，而是安全防护本身。2026 年 10 月，围绕 “Salesforce 抗钓鱼多因素认证” 的搜索量明显上升，大量用户并不清楚摆在自己面前的是什么：是必须响应的强制要求，还是某种需要清除的恶意软件？安全站点2-spyware.com随后刊发的指南给出了一种颇具代表性的澄清 —— 抗钓鱼多因素认证并不是需要卸载的程序，而是基于 WebAuthn 与 FIDO2 标准构建的登录功能；围绕它的真正风险，是伪装成技术支持的电话诈骗，即语音钓鱼。

这一澄清背后，折射出当前身份安全实践中的双重张力。一方面，随着钓鱼攻击的产业化与代理中转技术的成熟，传统的短信验证码、邮箱验证码与应用口令等第二因素正加速失效，安全产业与大型平台纷纷转向绑定站点地址的密钥型认证，以从根本上切断 “密码与口令可被中转” 的漏洞。另一方面，多因素认证的引入并非万能，其对特权账号的强制推行，以及它在真实攻击链中实际能够覆盖的环节，都需要冷静审视。本文即以此为对象，依次考察抗钓鱼认证的技术原理、适用范围、能力边界及其在纵深防御中的定位。

2 抗钓鱼认证的技术原理：绑定站点地址的非对称密钥

要理解抗钓鱼认证为何 “抗钓鱼”，需从两类认证因素的差异说起。以短信验证码、邮箱验证码、基于时间的一次性口令（TOTP）与推送确认为代表的传统第二因素，其共同特征在于：它们要么是 “可读取并输入” 的秘密，要么是 “可被点击确认” 的操作，而这些行为均可在钓鱼页面与真实站点之间被实时中转。攻击者只需构建一个高仿真的钓鱼站点，诱导受害者在伪造页面上输入验证码，再在数秒内将其转发至真实登录页面完成接管。此类攻击利用的是中间人式的中转逻辑，受害者输入的每一个字符，最终都会流向攻击者所控制的通道。

与之相对，基于 WebAuthn 与 FIDO2 标准的抗钓鱼认证，采用非对称密钥体制从原理上封堵了这一通路。在注册阶段，用户设备会生成一对密钥：私钥被安全地保存在设备内置的硬件安全模块或受保护存储中，仅能通过指纹、人脸或设备 PIN 等本地方式解锁，而公钥则提交给服务端保存。关键的设计约束在于，凭据与注册时绑定的站点地址一一对应：浏览器只会在该凭据所归属的真实域名下发起认证，当用户访问仿冒的钓鱼站点时，浏览器在该域名下并不存在可用凭据，登录过程自然失败，钓鱼页面也就拿不到任何可复用的信息。

这正是 “抗钓鱼” 一词的技术内核：并非用户更警惕，而是系统在设计上使 “交出秘密” 这一行为在物理层面变得不可能。设备上的私钥无处可读、无处可抄，也就无从谈起被话术套取。相比之下，验证码是可读的、可输入的，推送按钮是可点击的，这类 “由人参与传递” 的认证因素，恰恰是钓鱼代理所利用的缝隙。据此，短信验证码、邮箱验证码、应用口令与推送确认均被明确排除在抗钓鱼方法之外，这一判定并非出于偏好，而是由密钥体制与非密钥体制在 “是否可被中转” 这一属性上的本质差异所决定的。

3 适用范围的划定：特权用户与分层认证策略

围绕 Salesforce 抗钓鱼多因素认证的讨论，其另一个核心议题在于 “谁必须使用”。据多个第三方来源报告，Salesforce 正对特权用户提出抗钓鱼认证的强制要求，此类用户主要指系统管理员以及具有修改全部数据、查看全部数据、自定义应用程序等高权限的账号。对这些账号而言，短信验证码、邮箱验证码、应用口令与推送确认已不再满足合规要求，需改用安全密钥、通行密钥或设备内置认证器。

这一分层策略的合理性，可以从风险分布的角度加以理解。特权账号掌握着数据导出、配置修改与权限分配等关键能力，一旦被接管，攻击者能够以合法身份对组织数据进行大范围访问与破坏，其损失远超普通账号。因此，安全投入理应向高风险账号倾斜，以更高的认证强度匹配更高的权限级别。与之对应，普通内部用户仍需采用标准多因素认证，其中包括验证码与推送确认等方式；经由单一登录（SSO）访问的用户，则通常由身份提供方所采用的抗钓鱼方法承担认证责任，前提是身份提供方将所用方法如实传递给 Salesforce。这种 “按权限分层、按风险定级” 的思路，体现了身份治理从 “一刀切” 向精细化演进的趋势。

需要指出的是，上述范围与时间节点主要来自咨询机构、密码管理服务商与行业站点的报告，其彼此间在具体生效日期上存在出入。这也提醒组织，在落实此类要求时，应以平台官方文档与自身租户的实际配置为准，不宜仅凭第三方转述即作出一次性判断。分层认证的真正价值，不在于某个账号是否 “合规”，而在于认证强度与实际权限风险是否匹配。

4 能力边界：认证防护止步于哪一步

抗钓鱼认证最容易被误解之处，在于人们常把它等同于 “彻底抵御钓鱼”。事实上，它的防护作用严格限定于身份认证这一环节，对于认证之后发生的各类滥用行为并无直接效力。这一边界，在谷歌威胁情报组披露的 UNC6040 事件中得到了典型体现。

据该报告，攻击者以电话方式冒充企业技术支持，诱导已登录的 Salesforce 用户前往连接应用页面，批准一个伪装成 Data Loader 的恶意连接应用。用户批准后，该应用即获得持续查询并下载组织数据的权限。谷歌在报告中明确指出，这些案例中并不存在 Salesforce 自身的漏洞，被攻破的薄弱环节是电话那端的人。换言之，攻击者并未试图盗取用户的登录凭据，而是通过社会工程话术，让已在真实站点上完成认证的用户，主动完成了对恶意应用的授权。抗钓鱼认证在此场景中无能为力：私钥虽能阻止密码与验证码被中转，却无法阻止一个身份已验证的用户，出于信任而点击 “允许”。

这一案例揭示了一个重要的概念区分：认证（证明 “你是谁”）与授权（允许 “做什么”）是两个相互独立的安全环节。抗钓鱼认证强化的是前者，而 UNC6040 攻击利用的是后者 —— 即连接应用授权环节缺乏足够的管控。类似的边界还存在于其他场景：恶意软件若能窃取已登录浏览器中的会话令牌，则用户此前完成的认证同样无法挽回后续的会话接管；若攻击者能说服服务台重置认证方式或重新注册凭据，则再强的认证也会被恢复流程所绕过；若短信或应用口令仍保留在账号上，攻击者同样可以选择走那条较弱的路径。凡此种种，均说明抗钓鱼认证是 “防线中的一层”，而非 “防线本身”。

反网络钓鱼技术专家芦笛指出，对这类认证能力应避免两种认识偏差：一是高估，将其视为可以一劳永逸消除钓鱼风险的万能措施；二是低估，因某个案例中它未能阻止全部攻击而否定其价值。芦笛强调，衡量抗钓鱼认证的真实效用，应看它在攻击链中所能切断的环节 —— 它确实有效切断了 “密码与验证码经钓鱼代理被中转” 这一主流接管路径，但组织必须清醒地认识到，攻击者会向认证难以覆盖的其他环节转移，尤其是授权滥用与人因环节。对此，芦笛建议在部署认证升级的同时，同步评估连接应用审批、权限授予与账户恢复等 “认证之后” 的流程是否具备同等强度的防护，否则认证强度的提升，可能只是将攻击面推向防护更薄弱的位置。

5 从认证到纵深防御：完整防线中的各层控制

对 UNC6040 事件的复盘，使 “认证只是纵深防御的一环” 这一判断变得更加具体。谷歌在报告中给出的加固建议，涵盖了认证之外的多个层面：限制连接应用的访问范围、落实最小权限原则、培训员工识别此类话术、监测异常的大批量数据查询与导出等。这些措施与抗钓鱼认证共同构成了一道层层递进的防线。

据 DiMiao，CN 对相关事件的梳理，可将针对此类攻击的防护归纳为四个相互衔接的层面。第一层是身份认证，通过抗钓鱼认证切断凭据中转路径；第二层是授权管控，对连接应用的创建、审批与 OAuth 授权实施审查与限制，使恶意应用即便被诱导批准也难获过宽的数据访问权限；第三层是访问审计，通过监测登录日志与 API 活动中异常的大批量查询与导出，尽早发现已发生的越权行为；第四层是人因防护，通过话术识别培训与 “挂断后回拨” 的行为约定，降低社会工程攻击的得手概率。迪妙安全研究团队在相关研究中亦观察到，单一控制措施的强化，若未与相邻环节协同，往往造成防护重心的转移而非风险的整体下降；认证升级必须与授权、审计与培训同步推进，才可能形成闭环。

这四层控制并非并列的选项，而是需要同时存在、相互补位的纵深结构。抗钓鱼认证解决的是 “入口能不能被钓鱼代理骗走凭据”，连接应用管控解决的是 “被批准的应用能拿到多少数据”，日志监测解决的是 “越权行为何时能被发现”，人因培训解决的则是 “人在对话中能否守住底线”。任何一层的缺失，都会成为攻击者转向的突破口。

6 面向组织的实施与治理建议

基于前述分析，组织在推行抗钓鱼认证时，宜遵循若干务实的实施原则，以避免 “合规达标” 与 “实际安全” 之间的落差。

其一，为高风险账号优先注册并保留备用凭据。系统管理员等高权限账号应尽快登记安全密钥或通行密钥，并同时注册第二个备用方式，避免单一密钥丢失导致管理员无法登录而引发锁定风险。其二，及时退役弱认证因素。仅新增安全密钥而保留短信与应用口令，等于仍为攻击者留下一扇较弱的后门；应在确认新方法可用后，关闭旧的低强度方式。其三，将账户恢复流程的强度提升至与登录相当的水平。既然攻击者可能利用服务台重置或重新注册凭据的通道绕过认证，恢复流程就应与登录同等地受到严格审查与身份核实。其四，围绕认证之后的授权环节加强管控：审查连接应用清单与 OAuth 授权情况，撤销无法识别或疑似仿冒的应用，落实最小权限，尤其收紧数据导出类权限。其五，通过 “挂断并回拨可信号码” 的行为约定与真实案例培训，使员工在面对冒充技术支持的来电时具备可执行的应对方式，而非仅凭直觉判断。

需要强调的是，上述建议的落脚点，在于使组织把抗钓鱼认证纳入一个完整的治理框架，而非将其视为孤立的合规动作。认证强度、授权控制、审计能力与人因培训四者之间的匹配程度，决定了整体防护的实际水平。

7 结语

Salesforce 抗钓鱼多因素认证的讨论，提供了一个审视身份安全复杂性的清晰样本。基于 WebAuthn 与 FIDO2 的密钥型认证，凭借 “凭据绑定站点地址、私钥不离设备” 的设计，从原理上切断了传统第二因素可被钓鱼代理中转的路径，为特权账号提供了显著增强的认证保障。与此同时，UNC6040 语音钓鱼事件也清楚地划定了这一技术的边界：它保护的是 “你是谁” 的认证环节，却无法阻止已认证用户在真实站点上批准恶意应用，也难以抵御会话窃取与账户恢复绕过等认证之外的攻击。

本文的基本结论是审慎的：抗钓鱼认证是纵深防御体系中具有明确价值的一层，但其效力必须以相邻环节的同步强化为前提。将认证升级与连接应用管控、最小权限、日志审计与人因培训结合起来，使防护重心不因单一措施的强化而被动转移，才是此类技术得以发挥真实价值的途径。身份安全的改进，终究是一个各层控制协同演进的过程，而非某一项认证技术的单独胜利。

编辑：芦笛 （公共互联网反网络钓鱼工作组）

来源：迪妙网络空间安全学院