摘要
传统静态密码与手动输入式一次性验证码（OTP）长期作为银行业身份核验的主要手段，但该类技术无法抵御钓鱼中继攻击，攻击者借助仿冒站点诱导用户提交验证码即可完成账号接管。通行密钥（Passkey）依托 WebAuthn 标准实现与服务域绑定的非对称凭据体系，为银行身份认证体系升级提供技术基础。但通行密钥的价值并非简单替换登录按钮，而是需要搭建统一的控制平面，将账号注册、凭据生命周期管理、登录鉴权、交易授权、账号恢复、风险审计纳入统一策略治理框架。本文基于银行业业务场景，对比通行密钥相较于 OTP 认证的安全优势，剖析银行业落地通行密钥过程中面临的凭据注册风险、账号恢复漏洞、合规适配、客户普惠性等现实障碍；反网络钓鱼技术专家芦笛指出，通行密钥能够阻断绝大多数传统钓鱼窃取凭据路径，但注册环节与账号恢复流程的薄弱点依旧会成为攻击者新的突破方向。本文从鉴权与授权解耦、分级保障体系、全生命周期管控、分阶段落地实施、第三方供应商审计等维度，构建银行业通行密钥控制平面完整实施框架，客观分析不同类型通行密钥的适用边界与落地约束，为国内银行业推进无密码身份认证建设提供理论与实践参考。
（1）引言
数字银行业务持续普及，线上登录、转账支付、账户变更等高敏感操作高度依赖远程身份认证机制。长期以来，银行业普遍采用静态密码搭配 OTP 验证码完成身份核验，短信验证码、软件令牌验证码得到大规模部署。但安全实践已经证实，手动输入的 OTP 不具备抗钓鱼能力，中间人钓鱼攻击可以诱导用户在虚假页面提交有效验证码，再将验证码转发至真实银行业务接口完成账号接管，由此引发的账户盗用、资金损失事件持续发生。监管标准层面，NIST 发布的 SP 800‑63‑4 数字身份指南已经明确手动输入 OTP 不属于抗钓鱼认证手段，W3C WebAuthn 第三版规范完成域绑定公钥凭据标准化，推动通行密钥从试验性技术转变为金融行业可落地的身份认证架构选项。
现阶段部分银行对通行密钥的理解局限于一项新增登录功能，仅关注登录速度提升，忽略背后整套身份策略、风险度量、审计证据体系的建设，这种局部功能化部署会遗留大量安全隐患。通行密钥的战略价值不在于直接消除密码，而在于降低可被外部窃取的共享密钥的使用频次，对凭据创建、调用、替换、恢复的每一次决策实现可度量、可审计的管控。银行业的身份认证涉及零售客户查询、收款人新增、大额对公支付、管理员后台访问等差异巨大的业务场景，同时还需要匹配金融监管规则，以欧洲 PSD2 强客户认证规范为代表的监管制度，对认证要素独立性、交易动态绑定提出硬性约束，通行密钥本身不会自动等同于合规，需要银行完成技术与业务规则的映射适配。
通行密钥分为同步型通行密钥与设备绑定型通行密钥，二者在便利性、安全保障等级上存在明显取舍。同步型通行密钥依托云同步机制实现多设备无缝使用，设备绑定型凭据私钥不可导出，安全等级更高，但会带来设备丢失后的账号恢复难题。银行不能简单选用单一类型凭据覆盖全部业务，需要建立分级保障机制。同时，账号恢复流程是整套体系中最容易被忽视的薄弱环节，如果通行密钥实现高强度认证，但账号恢复依旧依赖安全防护薄弱的客服中心或者邮件链接，攻击者依旧可以绕开整套防护体系接管账户。除此之外，客户设备差异、无障碍访问需求、第三方身份服务商的架构黑箱，都是落地过程中必须解决的现实问题。基于上述行业现状，本文解析通行密钥的安全机理与银行业应用困境，提出完整的控制平面建设路径，探讨 120 天分阶段落地模式，客观评估各类方案的收益与局限。
（2）通行密钥相较于 OTP 认证的安全逻辑与银行业应用价值
传统密码与 OTP 属于共享秘密认证模式，服务端与用户侧掌握同一套秘密信息。当用户遭遇钓鱼网站欺骗，秘密信息就会泄露给攻击者。通行密钥基于非对称密码机制，私钥保存在用户终端本地安全载体内部，银行服务端仅存储对应的公钥。每一次认证过程，终端私钥针对服务端下发的随机挑战完成签名，同时凭据强制绑定业务服务方标识，仿冒域名无法调用该银行对应的通行密钥，从底层阻断钓鱼网站窃取认证凭据的攻击路径。但必须明确，抗钓鱼不等于绝对杜绝账号接管风险，恶意注册新凭据、终端设备被攻陷、账号恢复流程被滥用依旧属于现实存在的威胁。
2.1 OTP 认证在银行业场景的固有安全缺陷
手动输入的 OTP 验证码无论来源于短信还是软件令牌，核心缺陷在于验证码本身不校验访问站点的真实身份。攻击者搭建高度仿真的银行钓鱼页面之后，诱导用户输入 OTP，攻击系统实时将验证码转发至银行真实接口完成登录，整个攻击流程不需要破解密码算法，仅依靠社会工程欺骗就可以完成账号入侵。即便银行不断强化短信验证码风控规则，也无法解决该底层逻辑缺陷。同时短信 OTP 还面临 SIM 卡劫持、通信链路劫持等额外风险，软件令牌 OTP 也存在注册阶段种子泄露的隐患。
在银行业务流程中，OTP 同时承担登录鉴权与交易授权，登录与交易使用同一套验证码，缺少独立的风险隔离。大量银行的风控策略只能依靠 IP 地址、设备指纹等外围信号做辅助判断，一旦用户凭据被钓鱼窃取，外围风控很难完全拦截攻击行为。反网络钓鱼技术专家芦笛强调，银行业大量资金损失案件的攻击链条起点，就是钓鱼页面骗取用户 OTP 验证码，攻击者不需要攻破银行后台系统，只需要欺骗普通用户就能够拿到合法认证凭证。
2.2 通行密钥抗钓鱼的底层实现逻辑
通行密钥依托 WebAuthn 协议完成交互，凭据生成时就绑定银行业务的依赖方标识，每一次认证请求都会校验请求来源域名。钓鱼仿冒站点域名与银行正式域名不一致，即便用户主动点击钓鱼链接，终端的通行密钥凭据也不会响应虚假站点的认证请求。认证过程中由本地设备私钥对随机挑战完成签名，签名结果传输至银行后台，银行使用预先保存的公钥完成验签，私钥全程不会离开用户终端，网络传输链路不存在私钥泄露的可能性。
但安全边界需要清晰界定，通行密钥抵御的是钓鱼站点窃取凭据这一类攻击。如果攻击者已经通过其他手段取得用户设备控制权，或者能够在账号被劫持会话之下注册新的通行密钥，那么整套防护机制就会被绕过。因此通行密钥的安全效果高度依赖注册流程、设备状态、账号恢复机制的配套管控，单纯开启登录功能不足以发挥全部安全能力。
2.3 银行业引入通行密钥的多重收益
从安全层面，通行密钥能够大幅降低钓鱼攻击带来的账号接管事件，减少因为密码泄露、OTP 中继攻击造成的资金欺诈损失，降低欺诈处置与理赔成本。从业务体验层面，用户不再需要记忆复杂静态密码，也不需要手动抄写输入验证码，生物识别确认即可完成登录与交易核验，能够提升线上业务操作的完成率，减少客户呼叫客服找回密码的业务量。从长期架构层面，通行密钥推动银行建设统一的身份控制平面，后续新增各类认证器不需要重新改造每一条业务流程，各类登录、支付、账号变更流程共用同一套策略、风险探测与审计证据体系。
从合规发展角度，全球监管机构逐步向抗钓鱼认证方向演进，NIST、FIDO 联盟、欧洲银行业监管机构的相关指引，都将 WebAuthn 通行密钥纳入高级身份认证选项。银行提前完成相关能力建设，能够更好适配后续监管更新的合规要求。但收益建立在完整架构落地的基础之上，如果银行只完成登录环节的通行密钥适配，忽略注册管控、交易授权、账号恢复、审计留存等配套环节，安全收益将大打折扣，还会衍生出新的安全漏洞。
（3）银行业落地通行密钥的核心风险与现实困境
很多银行在推进通行密钥建设时，容易将其视作一项独立的登录功能开发，没有站在控制平面的视角统筹全部身份相关业务，导致各类风险点残留在业务链条当中。主要风险集中在凭据注册管控缺失、鉴权和交易授权混淆、账号恢复流程漏洞、不同类型凭据安全等级混用、普惠性适配不足、第三方服务商黑箱风险等方面。
3.1 凭据注册环节的恶意新增凭据风险
凭据注册是通行密钥全生命周期中风险最高的环节，其风险等级不亚于大额转账操作。如果攻击者劫持用户已有的会话，就可以直接为账户注册属于攻击者的通行密钥。后续攻击者使用该恶意注册的凭据登录，密码学层面的签名全部合法，银行仅凭认证签名本身无法分辨该凭据是否为用户本人自愿注册。
现实业务中，账号密码重置、SIM 卡更换、用户预留联系方式变更、设备更换之后，往往伴随凭据注册操作，这些场景本身属于高风险操作。如果注册环节缺少独立的风险引擎、冷却机制、跨渠道通知，攻击者就可以利用账号变更窗口期恶意注册凭据。同时银行还需要管控凭据无序扩张的问题，同一个账号下注册大量无标记、无使用记录的通行密钥，运维人员无法分辨凭据对应的设备，发生账号异常之后无法快速撤销风险凭据，形成凭据管理盲区。
3.2 身份鉴权与交易授权逻辑边界混淆
通行密钥完成登录只代表证明用户掌握某一份凭据，并不等同于用户确认执行某一笔资金交易。部分银行在开发过程中将登录鉴权与交易授权合并处理，只要通行密钥完成登录，就直接放行转账、新增收款人等高风险操作，这是典型的实现误区。登录行为确认账号身份，交易授权确认用户对本次特定交易的主观意图，二者应当作为相互独立的策略对象，即便使用同一台设备的通行密钥，登录和交易审批也应当走独立的策略校验流程。
该问题在欧洲 PSD2 强客户认证规则场景下尤为突出。PSD2 要求远程支付认证要素相互独立，并且认证过程需要与交易金额、收款方信息动态绑定。通行密钥登录产生的密码学证据，不能自动等同于满足支付授权监管要求，银行必须完成业务逻辑与监管条文之间的映射，把交易要素展示、授权代码生成、认证要素独立性校验完整纳入流程，不能直接默认部署通行密钥即自动达成合规。
3.3 账号恢复机制的安全短板
通行密钥减少密码依赖的前提条件是账号恢复路径不能引入同等的安全弱点。如果通行密钥全部失效，账号恢复流程就成为攻击者绕开整套无密码体系的突破口。部分银行直接沿用传统的邮件链接、客服人工核验的恢复模式，没有针对通行密钥场景重新设计恢复产品。
同步型通行密钥还引入云同步体系的外部依赖，凭据存储在平台服务商的加密同步架构中，该同步服务自身的账号安全会间接影响银行账号安全。NIST 相关指引明确要求同步凭据的存储访问必须具备等同于 AAL2 等级的多要素防护，银行需要评估客户使用的同步环境是否达到安全基线。另外，无论采用哪一种恢复路径，恢复完成之后都应当设置风险观察窗口期，窗口期内限制新增收款人、大额转账、注册新凭据等高风险动作，同时加强风险监控，避免账号恢复环节被恶意利用。
3.4 凭据分级缺失，安全等级与业务风险错配
零售账户余额查询、普通客户转账、企业大额对公支付、银行内部管理员后台访问，不同业务操作带来的风险后果差异巨大。同步型通行密钥与设备绑定型通行密钥安全保障等级存在明确区分：同步型凭据可以跨多设备流转，用户使用便捷，但依托第三方云同步服务；设备绑定型凭据私钥不可导出，安全等级更高，但是设备损毁之后凭据直接失效。
如果银行使用同一套全局策略，不区分凭据保障等级和业务风险，就会出现安全与业务的错配。普通零售客户日常账户查询场景，使用同步通行密钥可以兼顾便捷与安全；但是企业管理员账号、大额对公支付场景，继续使用同步凭据，就会带来超出业务容忍度的风险。部分银行缺少明确的保障等级划分，没有把凭据类型和业务风险场景做绑定，高风险业务使用保障能力不足的凭据，埋下安全隐患。
3.5 用户普惠性、可访问性与迁移指标误区
通行密钥的落地不能只面向持有新型智能设备的用户。市场上存在大量不支持通行密钥的老旧终端，部分用户无法使用生物识别，还有共用设备、委托代理账户、联名共管账户等特殊业务场景。如果直接取消密码、OTP 等备选认证方式，会造成部分客户无法正常办理银行业务，被迫退回到安全性更差的人工异常流程，反而扩大整体风险面。
很多机构把通行密钥注册数量作为核心考核指标，将注册量等同于安全建设成效。注册规模属于表面指标，真正需要持续观测的指标包括登录成功率、密码重置频次、钓鱼欺诈损失率、账号接管事件数量、误拦截比例、客服恢复工单数量等。缺少完整观测指标体系，银行无法客观评估通行密钥上线之后的实际风险变化，难以识别不同用户群体的体验落差。
3.6 第三方供应商引入的架构审计难题
绝大多数银行不会从零开发整套通行密钥技术栈，普遍采购身份平台、移动安全组件、托管认证服务等第三方产品。选型阶段很容易被产品演示效果误导，只考察产品是否支持通行密钥功能，忽略底层协议处理、凭据证明模式、事件日志、策略管控能力的差异。不同供应商对于依赖方标识、用户校验标记、跨设备交互流程的处理存在区别，部分产品对外提供可用的登录能力，但是银行无法自主管控完整策略，审计日志、撤销接口、故障降级模式存在缺陷。同时还需要考虑服务商服务中断、后续更换供应商时凭据迁移的可行性，避免业务被供应商技术数据模型锁定。
（4）银行业通行密钥控制平面的整体构建路径
通行密钥控制平面是一套统一的策略、遥测、决策层，覆盖银行全部业务渠道。该控制平面需要持续回答五类核心问题：哪些主体有权限创建凭据；业务操作需要何等安全保障等级；凭据允许在哪些场景下使用；何种风险信号需要改变业务流程；银行如何留存证据证明操作合法。围绕该核心定位，从鉴权授权解耦、分级保障体系、凭据全生命周期管控、账号恢复体系建设、客户普惠设计、指标观测、分阶段实施、供应商审计多个维度搭建完整体系。
4.1 实现身份鉴权与交易授权的逻辑分离
银行在业务流程设计上，必须将账号登录鉴权、增强身份校验、交易授权拆分为相互独立的策略对象。即便同一通行密钥参与登录和支付审批，两类操作也需要执行独立的风险判断。登录环节只确认用户持有有效凭据；发起资金交易时，需要单独触发交易授权流程，在授权界面向用户完整展示交易金额、收款方信息，完成对应签名校验。
面向欧洲 PSD2 等监管场景，银行需要完成完整的规则映射，梳理认证三要素的对应关系、要素独立性校验逻辑，落实交易信息与授权签名的动态绑定。不能将通行密钥登录成功直接视作支付授权完成。登录完成之后，高风险交易依旧需要单独触发通行密钥二次授权，实现登录身份确认与交易意图确认的隔离，以此降低登录凭据被滥用带来的资金风险。
4.2 建立凭据保障分级体系，匹配业务风险等级
银行应当建立有限的几套保障配置文件，拒绝全局一刀切的配置模式。对于普通零售客户账户查询、小额日常访问，允许使用经过风险评估的同步型通行密钥；针对新增收款人、较高额度转账操作，提升保障等级；企业客户、银行内部管理员等高风险角色，强制使用设备绑定型、支持认证证明的高保障凭据。
参考 NIST 对于 AAL2 可导出密钥、AAL3 不可导出密钥的区分思路，结合银行业务风险划分安全基线。同步通行密钥允许用于低、中风险业务；设备绑定不可导出凭据用于高风险业务。每一类业务场景明确允许的凭据类型，同时结合交易额度、凭据注册时长、设备安全状态、异常行为信号触发增强校验。分级体系需要形成书面文档，得到管理层审批，每一类业务选择何种凭据保障等级都具备可追溯依据。
4.3 完成通行凭据全生命周期安全管控
凭据注册作为高风险账号变更业务，设置独立的风险控制逻辑。首次注册通行密钥，必须依托已经可信的认证因子，或者完成充分的身份二次核验；注册过程绑定当前会话，完整采集凭据类型、用户校验结果、设备信息、策略版本等证据数据。注册完成之后通过独立通信渠道向客户推送通知，账号后台提供清晰的凭据管理页面，每一份注册凭据展示可读标签、最近使用时间，支持客户主动撤销凭据。当账号发生密码重置、SIM 变更、联系方式修改等高风险事件之后发起凭据注册，自动启用增强风控逻辑。
运维层面防范凭据静默泛滥，增加凭据数量上限、重复凭据检测、凭据撤销状态管理，保障客户、风控运维团队都可以清晰掌握账号下全部凭据状态。当风险事件发生时，能够快速撤销可疑凭据。凭据撤销流程应当独立可用，不能依赖登录账号本身。
4.4 将账号恢复作为独立安全产品进行设计
银行不能复用旧的账号恢复流程，需要搭建多路径的账号恢复体系，可选路径包括使用其他已注册通行密钥、银行侧设备绑定校验、高等级身份核验流程、受监督异常处理流程。每一条恢复路径明确定义能够达到的保障等级，以及恢复之后允许开展的业务动作。
使用同步型通行密钥时，银行需要对云同步架构提出安全基线，确认同步环境具备加密存储、访问控制、等同于 AAL2 等级的多要素保护，明确当外部同步生态发生账号泄露时银行的处置逻辑。启用恢复风险观察窗口，在通过安全强度较弱的路径完成账号恢复之后，一段时间之内限制新增收款人、注册凭据、大额转账等高风险操作，同时提升该账号的监控力度。账号恢复的目标是恢复客户账号访问权限，不能让恢复通道成为攻击者接管账号的便捷路径。
4.5 面向多元客户群体开展普惠与可访问性设计
银行的业务覆盖不同设备条件、身体条件的客户群体，通行密钥建设不能以牺牲部分用户正常服务能力为代价。银行需要完整测试 APP、移动端浏览器、桌面浏览器、人工辅助服务、联名委托账户等全部业务场景。跨设备扫码认证流程的交互提示语言需要清晰明确，避免用户产生操作误解。共管账户、企业角色账号，凭据绑定对应使用人以及岗位角色，而不是共用一套登录凭据。
针对没有新式设备、无法使用生物识别、共用设备的客户，持续保留安全的备选认证路径。开展无障碍测试，覆盖读屏软件、切换控制操作、认知负荷、二维码交互等场景。建立度量指标，统计不同客户群体业务完成成功率，统计客服工单数量，避免安全升级将一部分用户推向安全性更弱的人工例外处理通道。同时面向普通客户开展通俗易懂科普，说明生物识别数据保存在本地设备，不会直接上传银行服务器，消除用户对生物信息泄露的顾虑。
4.6 构建以风险结果为导向的观测与度量体系
摒弃单纯统计注册数量的评价模式，上线之前采集业务基线数据，将开通通行密钥的用户群体与参照对照组开展对比。重点观测指标包含登录成功完成率、密码重置数量、OTP 调用频次、钓鱼引发账号接管事件、误拦截比例、账号恢复工单量、每千次认证对应的客服咨询数量、凭据撤销数量。
遥测数据需要保存完整决策上下文，银行应当能够回溯每一次认证调用执行了哪一套策略、认证器返回的标记信息、风险信号情况、是否触发增强校验以及背后的原因。完整证据留存服务于风险模型调优、安全事件响应、客户投诉处理以及合规审计工作。通过持续观测数据，决定业务推广节奏，只有在业务完成率没有下降，欺诈损失没有恶化的前提下，才可以进一步扩大通行密钥的业务覆盖范围。
4.7 执行 120 天分阶段落地实施路线
通行密钥不宜一次性全量上线，采用分阶段迭代模式降低业务风险。
第一阶段，上线后第 1‑30 天，梳理全部登录与账号恢复业务流程，划分各个业务场景的保障等级，完成监管规则映射，梳理暂不适合通行密钥的业务场景。
第二阶段，第 31‑60 天，开发凭据注册、管理、撤销、遥测相关功能，针对恶意注册、会话劫持、账号恢复滥用完成威胁建模，识别潜在攻击路径并补充控制措施。
第三阶段，第 61‑90 天，先面向内部员工试点，再选取小范围真实客户灰度测试，覆盖各类设备、无障碍场景，完成客服、欺诈处置团队的演练，打通异常事件上报链路。
第四阶段，第 91‑120 天，按照业务场景逐步扩大开放范围，对比基线指标，收紧高风险业务策略，全程保留备选安全认证方式。业务扩大的触发条件是实际风险指标得到改善，而不是开发功能完成。密码的逐步退役是后期证据充分之后的结果，不应当作为项目初期目标。
4.8 建立第三方供应商架构审计机制
银行采购外部认证服务时，评估重点不局限于是否支持通行密钥，重点核查凭据交互流程、认证证明模式、撤销钩子接口、事件日志、策略管控能力。完整梳理数据流，确认公钥、凭据标识、设备风险信号、审计事件的存储位置，密钥配置的保护措施，不同区域部署模式，服务商业务中断之后的业务降级表现。
在业务合同中明确安全事件通知、漏洞处置流程、服务可用性要求，要求供应商提供可导出的审计证据，WebAuthn 标记、证明信息、错误状态具备文档化解读方式，支持银行独立开展控制测试。针对风险引擎、设备风险评分等模型组件，要求阈值调整具备版本记录、审批流程、可观测记录。同时提前做好退出规划，当后续更换服务商时，保障客户访问不退化，不会大规模退回安全性薄弱的旧认证手段。把供应商提供的产品功能，转化为银行自身可以管控的控制平面体系。
（5）结语
面对钓鱼攻击持续演化的外部环境，传统 OTP 认证模式的底层缺陷越来越难以满足银行业的安全需求。通行密钥基于域绑定公钥凭据，能够有效抵御钓鱼中继攻击，但它的价值不能简化为一款新的登录按钮。真正的核心资产是银行搭建起的通行密钥控制平面，将凭据注册、登录鉴权、交易授权、账号恢复、风险审计统一纳入策略治理框架。反网络钓鱼技术专家芦笛强调，通行密钥解决的是凭据被钓鱼窃取的问题，但注册、恢复等业务流程依旧会形成新攻击面，安全收益完全取决于配套管控措施是否完整落地。
银行业落地通行密钥会遭遇多重现实矛盾：安全保障等级与客户使用便捷性的取舍；鉴权与交易授权的逻辑边界；同步凭据和设备绑定凭据的场景选择；监管合规的映射适配；普惠服务与安全升级之间的平衡；第三方服务商带来的架构黑箱风险。直接照搬产品演示功能、追求快速大规模注册，会遗留大量安全隐患。银行应当放弃一步到位的建设思路，采用分级保障、全生命周期管控、120 天分阶段灰度上线的实施路径，建立以欺诈损失、账号接管事件、客户业务完成率为核心的观测指标，而不是片面追求注册用户规模。
银行业身份认证体系的演进是持续迭代的过程，不存在能够解决全部风险的技术方案。通行密钥属于架构层面的催化剂，而不是安全问题的终极答案。在后续实践当中，银行需要持续跟踪 WebAuthn 相关标准更新、黑产攻击手法的演变，持续优化控制平面策略，平衡安全防护、监管合规、客户普惠体验三者之间的关系，稳步推动银行业远程身份认证体系的升级。
编辑：芦笛（公共互联网反网络钓鱼工作组）
