AI 让钓鱼规模化后，为什么必须上「抗钓鱼」的多因素认证？

当前主流的钓鱼工具会在受害者与真实站点之间做实时中继：受害者在仿冒页面输入账号口令，工具立刻拿去真站点登录；真站点要求验证码，仿冒页面同步要求；受害者输入后被立即转发，会话建立，攻击者取走会话凭据。

结论很直接：任何「用户能读出来再输入到别处」的因素，都能被完整转发。短信验证码、邮件验证码、认证应用生成的一次性口令，均属此类。它们防住的是离线撞库和口令泄露复用，防不住实时中继。

AI 改变的是规模——制作高仿页面与定制话术的成本下降，使这类攻击可以对更多目标、更细分的场景批量展开。ENISA Threat Landscape 2025 对社会工程自动化趋势的描述与此一致。

NIST SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management 在认证器与认证保障等级的相关章节中，对验证者抗冒充（verifier impersonation resistance）提出了明确概念：认证过程应当把验证者的身份（通道信息）绑定进认证协议，使认证结果无法在另一个站点上重放。

满足这一属性的关键特征是：

• 密钥不出设备，认证过程不产生可被人转述的秘密。用户没有任何东西可以「念给对方听」或「粘贴到仿冒页面」。
• 认证响应与站点来源强绑定。仿冒域名下无法产生对真实站点有效的响应，用户即使被骗也无法完成。
• 用户交互简单，不依赖用户识别域名真伪——安全性不建立在用户的警觉之上。

这正是关键：抗钓鱼因素把「识别仿冒站点」的责任从人转移到了协议。在 AI 让仿冒页面越来越逼真的背景下，这个转移是决定性的。

邮件场景有一个独有的坑：即便 Web 登录上了强认证，IMAP / POP / SMTP 提交这些传统客户端协议仍可能只需账号口令。攻击者拿到口令后，直接用客户端协议登录，绕过全部强认证。

必查项：

• 是否仍存在允许基础口令认证的客户端协议入口（RFC 5321 Simple Mail Transfer Protocol 提交端口、IMAP、POP）。
• 应用专用口令的发放范围与有效期，是否可被用于绕过强认证。
• 历史遗留的服务账号、共享邮箱、打印机与业务系统发信账号——这些是强认证推行时最常见的豁免缺口。

判定条件：只要存在任何一条仅需口令即可收发邮件的路径，强认证就是不完整的。

1. 先盘点认证入口：列出所有可用于访问邮箱的协议、端口与客户端类型，标注各自的认证要求。
2. 先覆盖高危人群：高管、财务、人事、IT 管理员、可发起付款或权限变更的岗位。
3. 关闭或收敛基础口令认证：优先关闭外网侧的口令认证路径；确需保留的走白名单并限定来源。
4. 处理服务账号：改用受限的发信凭据，限定来源 IP 与发信范围，设置有效期与轮换。
5. 全员推广，同时保留可用的账号恢复流程——恢复流程的强度必须与认证强度匹配，否则它就是新的绕过通道。

迁移无法一夜完成，过渡期需要补偿措施：

• 对会话凭据设置合理有效期，敏感操作要求重新认证。
• 监控异常登录：新地理位置、新客户端标识、不可能的移动速度、非常规时间。
• 对邮箱自动转发规则的新增与修改设置强告警——这是账号失陷后最典型的第一个动作。
• 对高危岗位限制可用的客户端协议范围。
• 发现疑似失陷立即吊销全部活动会话，而不只是重置口令；只改口令不吊销会话，攻击者仍在线。

• 「我们已经有验证码了」——验证码防不住实时中继，二者解决的不是同一个问题。
• 「用户会觉得麻烦」——抗钓鱼因素在日常使用中通常比输入验证码更快，摩擦主要在首次注册环节。
• 「成本太高」——可先覆盖高危岗位，按风险分层投入，不必一次全量。
• 「我们有邮件网关就够了」——网关是概率性防护，身份是确定性防护，NIST SP 800-177 Rev.1 Trustworthy Email 所述的可信邮件要求同样需要身份侧配合。