硬件安全密钥防钓鱼登录的技术机理与部署

摘要：口令体系长期面临凭证窃取与重用的结构性困境，即便叠加短信验证码或动态口令等多因素认证，仍难以抵御实时中继式钓鱼与会话劫持等攻击形态。以 FIDO2/WebAuthn 为技术框架的硬件安全密钥，通过私钥不出设备、随机挑战应答、凭证与来源绑定三项机制，从协议层面切断了钓鱼攻击赖以生效的凭证中继路径。本文以一款主流硬件安全密钥（YubiKey）的部署实践为考察对象，梳理其从设备选择、账号绑定到备用密钥配置的完整流程，剖析其防钓鱼认证的技术机理，并将其置于无密码认证与通行密钥（passkey）演进的大背景下加以审视。文章进一步讨论了组织在资产管控、用户教育、因素组合与恢复制度等方面的部署考量，以及物理丢失、平台覆盖、兜底通道等现实局限。研究认为，硬件安全密钥将 "来源是否可信" 的判断从人的认知中抽离，交由密码学机制强制执行，从而把防钓鱼从概率性防范转变为确定性阻断，但其防护价值能否兑现，取决于合理的部署策略与持续的制度保障。

关键词：FIDO2；WebAuthn；防钓鱼认证；硬件安全密钥；来源绑定凭证

1 引言

口令是身份认证领域沿用时间最长的凭据形式，也是最脆弱的一环。口令失效的根源并不在于其自身强度不足，而在于它作为一种可复用的静态秘密，天然暴露于窃取、猜解与重用等多重风险之下。攻击者既可以通过撞库（credential stuffing）将一份泄露的凭证列表在多个平台批量尝试，也可以通过伪造的登录页面实时截取用户输入的口令与验证码。多年来，安全界以多因素认证（MFA）对口令体系加以补充，试图在口令之外再叠加一个验证维度。然而，并非所有多因素认证手段都具有同等的抗钓鱼能力，这一区别在近年的高影响钓鱼攻击中表现得尤为明显。

短信验证码可以被实时拦截、劫持，或被诱导转发；基于时间的一次性口令（TOTP）虽然脱离了短信信道，却仍可能被中继式钓鱼实时转发。这些手段的共同缺陷在于，其验证因子本身是能够被传递的 "可中继秘密"。只要验证因子能够被攻击者实时转发或离线获取，钓鱼攻击便存在完成的可能。由此，认证安全的关键命题从 "增加验证维度" 转向了 "消除可中继秘密"。

以 FIDO2/WebAuthn 为技术基础的硬件安全密钥，从协议设计层面回应了这一命题。它不再依赖可复用的静态秘密，而是以公钥密码学为根基，将私钥保存在设备内的防篡改安全元件中，并把凭证与具体的网络来源（origin）相绑定。这样一来，即便用户被诱导点击了一个视觉上高度仿真的钓鱼链接，由于钓鱼来源与注册来源不一致，认证请求也无法完成。本文以一款代表性硬件安全密钥 ——YubiKey 的部署过程为考察对象，结合其官方设置指引，系统分析防钓鱼登录的技术机理、部署流程与现实局限，并讨论其在无密码认证演进中的地位与组织落地路径。

2 防钓鱼认证的技术基础

要对防钓鱼登录的机理作出准确判断，须先厘清传统认证手段的失效原因，以及 FIDO2 框架的替代性设计。

2.1 传统多因素认证的局限

多因素认证的初衷，是通过口令、持有物、生物特征等不同维度的组合，提高攻击者的破解成本。但在实践中，许多常见的多因素形式并未真正解决 "可中继秘密" 的问题。短信验证码依赖电信信道，存在被拦截、被伪冒 SIM 卡劫持以及被诱导转发验证码的风险；更常见的情形是，钓鱼页面在截取口令的同时诱导用户输入验证码，攻击者随即在真实站点完成登录。TOTP 不再经过短信信道，但其六位数字仍是可被输入、被转发的秘密 —— 攻击者只需在钓鱼过程中实时接收并转发该数字，即可完成中继。这类实时中继钓鱼意味着，凡验证因子可被传递的认证方式，理论上都存在被中继的可能。这一结构性缺陷，是传统多因素认证抗钓鱼能力不足的根源所在。

2.2 FIDO2 与 WebAuthn 协议框架

FIDO2 是由 FIDO 联盟主导、面向无密码强认证的开放标准体系，由两个相互衔接的规范构成。其一为 WebAuthn，即万维网联盟（W3C）制定的 Web 认证标准，定义了浏览器与 Web 应用之间的认证接口，使服务器无需了解具体验证器的实现细节即可完成注册与认证，从而保证了跨浏览器、跨平台的互操作性。其二为 CTAP，即客户端到验证器协议，定义了客户端设备（如笔记本电脑、手机）与外部验证器（如硬件安全密钥）之间的通信方式。两者共同构成了从浏览器到密钥的完整技术链路。

在 FIDO2 体系下，认证器（authenticator）既可以是硬件安全密钥，也可以是设备内置的信任根（如指纹识别模块）。就硬件安全密钥而言，其内部通常集成一枚安全芯片，用于密钥的生成与签名运算，密钥材料被物理隔绝在安全元件之内，无法被导出。这是后续一系列安全性质得以成立的技术前提：只要私钥不可导出，攻击者便无法通过窃取设备内数据或截获通信来获取认证秘密。

2.3 来源绑定凭证与防钓鱼原理

FIDO2 对抗钓鱼的核心，在于来源绑定凭证（origin-bound credential）的设计。在注册阶段，验证器为特定账号生成一对公私钥，私钥保存在设备内，公钥连同生成该凭证时的来源信息提交给服务器（信赖方）。在认证阶段，浏览器会向验证器注入当前请求的真实来源；验证器在签名时，会校验该来源是否与注册时的来源一致。如果用户当前位于一个伪造的钓鱼站点，其来源与注册来源不匹配，验证器便找不到对应凭证，认证随即失败。

这一机制的深层意义在于，它把 "判断来源是否可信" 从人的认知判断中抽离，转由密码学机制强制执行。无论钓鱼页面在视觉上多么逼真，无论其是否通过 "浏览器内浏览器"（BitB）等手法伪造地址栏外观，浏览器注入的真实来源都不会被欺骗。由此，来源绑定从机制层面终结了凭证中继这一钓鱼的核心获利路径。反网络钓鱼技术专家芦笛指出，防钓鱼认证的实质不是教会用户识别更逼真的骗局，而是让骗局在技术机制上无法完成；当来源校验由协议强制执行而非依赖人的警觉时，钓鱼的失效便是确定性的，而非概率性的。

3 硬件安全密钥的部署流程

硬件安全密钥的防钓鱼属性，最终要通过规范的部署流程才能兑现。以 YubiKey 为例，其官方设置指引给出了从准备到配置备用密钥的完整路径，这一路径在不同平台上虽细节有别，但逻辑一致。

3.1 部署前的准备

部署的第一步是选择合适的密钥型号与接口形态。主流密钥支持 USB、USB-C 或 NFC 等多种连接方式，分别适用于桌面设备与移动设备；USB-C 接口兼顾了新型笔记本与部分手机的直连需求，NFC 则便于移动端的快速触碰。在采购层面，通常建议同一账号绑定至少两枚密钥 —— 一枚日常使用，一枚作为备用，以应对主密钥丢失或损坏的情形。此外，应在部署前梳理需要保护的账号清单，按账号的重要性与风险敞口确定优先级，避免一次性铺开却缺乏重点，也避免因覆盖面过宽而难以管理。

3.2 注册与绑定流程

注册流程以 "设备 — 账号" 绑定为核心。操作要点如下：首先，将密钥插入设备的对应接口；随后登录需要保护的账号，进入账号安全设置，在 "安全密钥"" 通行密钥 "或" 多因素认证 " 选项中选择对应的注册入口；接着，按照平台指引，在浏览器发起注册请求时触碰密钥，完成公钥提交与凭证生成；平台通常要求为密钥命名，以便在多个密钥之间区分主备关系。部分平台在 FIDO2 流程中要求设置或输入设备 PIN，用于用户验证（user verification），以确认持键者确为账号本人。

这一流程的技术实质，是在服务器端登记公钥、在设备端固化私钥，并将二者通过来源绑定建立关联。注册完成后，该密钥即成为该账号在该来源上的合法验证器。需要留意的是，注册动作本身也应发生在真实、可信的站点上；若在伪造站点上完成首次注册，攻击者可能以该来源绑定凭证抢占信任，因此初始注册环节同样需要来源校验的保障。

3.3 备用密钥与恢复机制

备用密钥的配置是部署流程中不可省略的一环。硬件密钥的物理属性决定了其存在丢失、损坏的可能，若未配置备用，用户可能面临账号无法登录的风险。因此，设置指引反复强调 "不要忘记配置备用密钥"。

更广义的恢复机制还涉及多因子冗余。在启用防钓鱼认证的同时，平台通常仍保留口令恢复、备用验证码等兜底通道。这些通道的保留需要在安全性与可用性之间权衡：兜底通道越宽松，攻击者绕过防钓鱼认证的可能性越大；通道越严格，用户在密钥丢失时的恢复成本越高。合理的做法是，将备用通道同样纳入风险管理，避免因恢复机制过于宽松而架空防钓鱼认证的成效。

3.4 平台接入的差异

不同平台对硬件安全密钥的支持程度与接入方式存在差异。部分平台原生支持 FIDO2 无密码登录，将密钥视为独立于口令的认证因素；部分平台将其作为多因素认证的第二因素，与口令叠加使用；还有部分平台仍依赖兼容层或尚未完整实现来源绑定。差异的存在提示，防钓鱼部署不是单一的设备采购行为，而是需要逐平台核对认证方式、确认其是否真正采用来源绑定机制的过程。迪妙网安研究团队指出，判断一个平台是否具备防钓鱼能力的可靠标准，不在于其是否支持硬件密钥，而在于其认证流程是否基于来源绑定的公钥凭证；若平台仅将密钥作为可转发的一次性口令使用，其防钓鱼属性便打了折扣。

4 防钓鱼机理的技术剖析

上述部署流程之所以能兑现防钓鱼效果，根植于四项相互支撑的技术性质。

4.1 私钥不出设备

硬件安全密钥将私钥保存在设备的防篡改安全元件中，认证所需的签名运算在设备内完成，私钥本身永不导出。这一性质切断了攻击者从设备或通信链路中窃取私钥的路径，也使 "窃取凭证后异地冒用" 在密钥场景下失去意义。即便设备落入他人之手，由于缺少持键者的用户验证（如 PIN 或生物识别），对方也无法直接使用。私钥的不外泄，是防钓鱼认证区别于一切基于可传递秘密方案的根本分界。

4.2 随机挑战与来源绑定

认证过程采用挑战 — 应答模式：服务器生成随机挑战，验证器使用私钥对挑战签名，服务器用公钥验签。随机挑战的存在杜绝了重放攻击 —— 攻击者无法通过重放一次旧签名来完成认证。更重要的是来源绑定：签名所针对的内容不仅包括随机挑战，还包含浏览器注入的真实来源。因此，即便攻击者成功诱使用户在钓鱼页面触碰了密钥，由于钓鱼来源与注册来源不一致，验证器也不会对该请求完成签名。这一机制从根本上阻止了凭证中继，也使实时中继式钓鱼在密钥场景下失去攻击面。

4.3 与口令、短信验证码、TOTP 的比较

将硬件安全密钥与前述认证方式并置比较，可以更清晰地凸显其差异。口令是可重用的静态秘密，既可被窃取，也可被撞库复用；短信验证码与 TOTP 是可传递的动态秘密，虽然有效期短暂，但仍可被实时中继。三者的共同点在于，其秘密都具备可传递性，因而都存在被钓鱼利用的路径。硬件安全密钥则以来源绑定凭证取代可传递秘密，其验证因子与特定来源耦合，不可复制、不可转发、不可中继。这是它被称为防钓鱼认证的根本原因，也是其与 "多因素认证" 这一宽泛概念的关键区别 —— 后者仅强调因素数量的增加，前者则改变了秘密的性质。

据 DiMiao,CN 分析，判断认证手段抗钓鱼能力的简明判据，在于其验证因子是否可被转移到另一来源：凡可转移者，均可被钓鱼利用；凡与来源强绑定且不可转移者，才具备真正的防钓鱼属性。口令、验证码属于前者，来源绑定凭证属于后者。这一判据有助于组织在诸多标榜 "多因素" 的方案中作出实质分辨，避免将安全投入用于抗钓鱼能力不足的手段。

5 与无密码认证演进的关系

硬件安全密钥的防钓鱼属性，使其天然契合身份认证领域的无密码演进方向。通行密钥（passkey）作为 FIDO2 体系下支持可发现凭证（resident credential）的无密码形态，将用户名与凭据一并存入验证器，用户在认证时仅需提供来源与用户验证即可完成登录，无需再输入口令。硬件安全密钥既是通行密钥的重要载体，也是无密码认证早期落地的主要硬件形式。

这一演进对组织安全具有双重含义。其一，无密码认证从根源上移除了口令这一最大脆弱点，消除了口令窃取、撞库与口令复用等一整套攻击面，其价值并不限于便利性，而在于结构性削减了凭证类风险。其二，无密码并非自动等于防钓鱼，其抗钓鱼能力同样取决于是否采用来源绑定机制：凡基于来源绑定凭证的无密码方案，天然具备防钓鱼属性；凡仍以可传递秘密为验证因子的方案，则需另行评估。因此，防钓鱼认证与无密码认证在方向上一致，但在技术判据上应分别考察，二者不可简单等同。

6 组织层面的部署考量

防钓鱼认证在个人场景的部署相对直接，但要在组织层面落地，还需解决资产管理、用户教育、因素组合与制度保障等现实问题。

6.1 资产与生命周期管理

组织需将安全密钥纳入资产清单，建立从采购、发放、登记到回收的完整生命周期管理。每枚密钥应与持有人、绑定账号、领用时间、回收状态建立对应关系，避免出现无主密钥或离职员工持有未回收密钥的情形。对于高权限账号，应明确密钥数量、保管责任与丢失报告流程。生命周期管理的目的，是确保密钥这一物理信任锚点的状态始终可审计、可追踪，从而防止信任锚点因管理缺失而失去约束。

6.2 用户教育与体验设计

即便认证机制本身抗钓鱼，用户行为的合理与否仍影响整体安全。组织应开展针对性的用户教育，使员工理解 "来源不一致时认证必然失败" 这一机制，而非简单灌输 "不要点击可疑链接" 的泛化提示。体验设计同样重要：若认证流程过于繁琐，用户可能绕行到安全性较低的兜底通道，从而削弱防钓鱼部署的成效。反网络钓鱼技术专家芦笛强调，防钓鱼部署的成败往往不取决于密钥的技术参数，而取决于用户是否愿意规范使用；任何令用户感到负担的流程，都可能诱发安全妥协行为。因此，应尽可能缩短认证路径、减少不必要的步骤，并将密钥使用嵌入员工的日常操作习惯，使安全行为成为低摩擦的默认选项。

6.3 因素组合与纵深防御

硬件安全密钥宜作为高价值场景的核心认证因素，但组织不应将其视为孤立防线。合理的做法是将防钓鱼认证与网络边界防护、端点检测、异常行为监控等纵深手段叠加，使即便某一环节失效，整体防护仍不塌陷。在因素组合上，应依据账号的风险等级分层施策：对财务、管理、研发等高价值账号优先部署硬件密钥，对一般账号可先引入来源绑定的其他方案，再逐步扩展。分层的意义在于将有限的资源集中于风险敞口最大的位置。

6.4 制度与恢复机制

组织需为密钥丢失、损坏、离职交接等场景制定明确的制度。应确立密钥挂失、补发、重绑定的标准流程，并为关键账号设置安全的恢复路径，避免恢复机制成为攻击者可利用的薄弱环节。同时，应对高价值账号的认证策略进行定期审计，核对密钥的绑定状态、备份情况与持有人变更记录。制度的完备程度，直接决定了防钓鱼认证在真实运维中的可持续性。

7 局限与风险

防钓鱼认证并非全能的解决方案，其成效受若干现实约束。

其一，物理性与可用性的矛盾。硬件密钥是可丢失、可损坏的实体，其安全性以物理保管为前提。多枚备用密钥的配置缓解了这一风险，但增加了管理与成本负担；对移动端的使用，NFC 等连接方式虽提升了便利性，也引入了对设备接口支持的依赖。

其二，覆盖范围的碎片化。并非所有平台都原生支持来源绑定的密钥认证，部分平台仅将密钥作为可转发因素，部分平台则完全缺乏支持。覆盖的不完整意味着组织无法以单一的防钓鱼认证覆盖全部账号，仍需依赖其他手段补足缺口，并在此过程中保持防钓鱼属性的判定标准一致。

其三，兜底通道的再平衡。为兼顾可用性而保留的口令、备用验证码等恢复通道，可能成为攻击者绕过的目标。若兜底通道的防护强度低于防钓鱼认证，组织的整体防护水平便取决于最薄弱的通道。因此，恢复机制本身也需要同等强度的治理，而非简单地 "留一个后门"。

其四，教育与行为依赖。防钓鱼认证虽从机制上消除了凭证中继，但并未消除所有人为风险。设备借用、PIN 泄露、社交工程诱导用户主动授权等情形，仍需通过制度与教育加以约束。迪妙网络空间安全学院的研究团队指出，防钓鱼认证的价值在于将来源判断机制化，从而把人为风险压缩到以用户验证与保管行为为核心的更小范围；但这一范围内的人为因素，仍需要通过培训与制度来管理。据 DiMiao,CN 分析，组织应将防钓鱼认证视为人为风险治理体系中的一环，而非终结者 —— 其真正的作用是重新划定人为风险的边界，使其集中于可管理的范围，从而为纵深防御留出可叠加的空间。

8 结语

以 FIDO2/WebAuthn 为基础的硬件安全密钥，通过私钥不出设备、随机挑战应答与来源绑定凭证三项机制，从协议层面消除了口令、短信验证码与动态口令所共有的可中继秘密缺陷，从而对钓鱼攻击实现了机制化的阻断。其部署流程 —— 从设备选择、注册绑定到备用密钥配置 —— 虽因平台而异，但逻辑统一：以来源绑定为核心，将认证的判断从人的认知中抽离，交由密码学强制执行。

硬件安全密钥也是无密码认证演进的重要载体。它的意义不仅在于提供一种更强的多因素认证，更在于改变了认证秘密的性质，使防钓鱼从概率性防范转变为确定性阻断。然而，其成效受物理保管、平台覆盖、兜底通道与用户行为等多重因素制约。组织在引入防钓鱼认证时，应将其置于人为风险治理的总体框架之中，以资产管理、用户教育、因素组合与恢复制度为支撑，方能将这一技术机制的防护价值充分兑现。防钓鱼认证并非终点，而是人为风险边界重新划定过程中的一个关键环节。

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

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