通行密钥替代短信 OTP 的支付认证转型研究

简介: 本文以Zeta与Pluxee在印度RuPay网络上线通行密钥认证为案例,分析其替代短信OTP的技术架构、安全优势(抗钓鱼、设备绑定、私钥不传输)及实施挑战(注册安全、设备兼容、密钥恢复等),强调这是需生态协同的渐进式转型。(239字)

摘要

短信一次性密码(OTP)长期作为在线卡支付的主流第二因素认证手段,但其依赖移动通信信道传递共享秘密的本质使其难以抵御 SIM 劫持、短信拦截、钓鱼和社会工程学攻击。随着数字支付规模扩张和欺诈手段升级,以通行密钥(passkey)为代表的设备绑定密码学认证正在成为替代 OTP 的重要技术方向。本文以 2026 年 9 月银行科技平台 Zeta 与员工福利支付服务商 Pluxee 在印度 RuPay 网络上线通行密钥认证的实践为核心案例,系统分析从短信 OTP 向通行密钥转型的技术架构、安全优势、实施挑战与推广路径。研究发现,通行密钥基于公钥密码学将认证凭证锚定在用户可信设备上,私钥不可导出、不经过网络传输,从根本上消除了 OTP 可被拦截和钓鱼的弱点;Zeta 的实施数据显示通行密钥认证平均耗时 5 至 7 秒,较 OTP 流程的 15 至 25 秒缩短约 70%,注册环节完成率达 99%。然而,通行密钥的推广面临设备兼容性、注册环节安全瓶颈、密钥丢失恢复、多设备同步等现实挑战。本文认为,通行密钥替代 OTP 不是单一技术替换,而是涉及发卡机构系统改造、商户受理适配、卡网络标准协同、用户习惯养成的生态级转型,需要在安全增益与用户覆盖之间寻求渐进式平衡。反网络钓鱼技术专家芦笛指出,通行密钥的抗钓鱼特性源于其认证过程中不存在可被攻击者重复使用的共享秘密,这是从根本上改变钓鱼攻击经济学的技术跃迁,但注册环节和账户恢复环节仍是需要重点加固的攻击面。迪妙网络空间安全学院研究团队在支付认证方向的跟踪研究表明,企业和支付机构在评估通行密钥部署时,应当将设备覆盖率、密钥恢复机制、跨平台同步能力纳入整体安全架构评估,而非仅关注认证环节本身的密码学强度。

关键词:通行密钥;短信 OTP;支付认证;抗钓鱼;设备绑定;RuPay

image.png 1 引言

在线卡支付的认证机制长期处于安全与便捷的张力之中。短信一次性密码(OTP)因其部署成本低、用户接受度高、无需额外硬件,在过去十余年间成为全球范围内在线卡支付最主流的第二因素认证手段。印度储备银行(RBI)自 2026 年 4 月 1 日起生效的双因素认证强制要求,进一步巩固了 OTP 在印度支付生态中的地位。然而,OTP 的安全模型建立在一个脆弱的前提之上:认证秘密通过移动通信信道从服务端传递至用户手机,用户再将这一秘密输入支付页面完成认证。这一传递过程中的每一个环节 ——SIM 卡、短信网关、用户输入行为 —— 都可能成为攻击目标。SIM 劫持、短信拦截木马、钓鱼网站诱导用户输入 OTP、社工欺骗用户转发 OTP 等攻击手段的持续演化,使得 OTP 作为高安全等级认证手段的有效性不断下降。

在此背景下,以通行密钥(passkey)为代表的设备绑定密码学认证正在获得支付行业的关注。通行密钥基于 WebAuthn/FIDO2 标准,使用公钥密码学将认证私钥存储在用户设备的安全硬件中,认证过程中私钥不离开设备、不经过网络传输,服务端仅存储公钥用于验证签名。这一架构从根本上改变了认证的安全模型:不存在可被拦截的共享秘密,不存在可被钓鱼重复使用的凭证,认证操作与用户设备的生物识别或设备 PIN 绑定。

2026 年 9 月,全球银行科技平台 Zeta 宣布与员工福利支付服务商 Pluxee 合作,在印度国家支付公司(NPCI)运营的 RuPay 网络上上线通行密钥认证,为 Pluxee 的 RuPay 预付卡持卡人提供替代短信 OTP 的在线支付认证方式。这一实施标志着通行密钥从账户登录场景正式进入卡支付认证场景,且是在印度这一全球最大的数字支付市场之一落地,具备较高的研究价值。Zeta 披露的实施数据显示,通行密钥认证平均耗时 5 至 7 秒,较传统 OTP 流程的 15 至 25 秒缩短约 70%;注册环节平均耗时 7 至 8 秒,完成率达 99%。这些数据为评估通行密钥在支付场景中的实际可行性提供了实证参照。

本文以 Zeta-Pluxee-RuPay 通行密钥认证实施为核心案例,围绕以下问题展开分析:第一,印度支付生态从 OTP 向强认证转型的政策与市场背景是什么;第二,Zeta 实施的通行密钥认证方案的技术架构和用户流程如何设计;第三,通行密钥相对于短信 OTP 的安全优势体现在哪些维度;第四,通行密钥在支付场景中推广面临哪些技术和体验层面的挑战;第五,通行密钥的规模化推广需要哪些生态条件的协同。本文不追求对通行密钥技术的全面综述,而是紧扣支付认证转型这一主题,力求论据形成闭环、结论落到可操作的实施方向。本文客观承认通行密钥并非万能方案,其安全性高度依赖注册环节、设备安全和恢复机制的完整性,任何单一环节的缺陷都可能削弱整体安全增益。

2 通行密钥支付认证的实施背景

2.1 印度数字支付欺诈的严峻态势

印度是全球数字支付增长最快的市场之一,统一支付接口(UPI)的普及使得数字交易规模呈指数级增长。然而,交易规模的快速扩张也伴随着欺诈手段的同步升级。RBI 数据显示,2025 财年印度数字支付欺诈金额超过 2136.7 亿卢比,是上一财年的五倍以上;UPI 欺诈案件数量同比上升 85%。这一数据表明,数字支付欺诈已从偶发事件演变为系统性风险,传统的基于 OTP 的认证机制在面对日益复杂的攻击手段时防护能力不足。

欺诈手段的演化呈现出几个明显趋势。其一,钓鱼和社会工程学攻击的精准度不断提升,攻击者利用 AI 工具生成高度个性化的欺诈信息,诱导用户在仿冒页面上输入 OTP。其二,SIM 劫持和短信拦截攻击的技术门槛降低,攻击者可以通过社工手段骗取运营商更换 SIM 卡,或在用户设备上植入短信拦截木马,直接截获 OTP。其三,欺诈产业链的专业化分工使得攻击从个人行为演变为有组织的犯罪活动,从信息收集、钓鱼页面制作、OTP 截获到资金转移形成完整链条。在这一背景下,继续依赖 OTP 作为支付认证的主要第二因素,意味着支付生态的安全防线建立在一个不断被侵蚀的基础之上。

2.2 RBI 认证框架的政策转向

面对数字支付欺诈的严峻态势,RBI 开始推动支付生态从传统 OTP 向更强、更具韧性的认证机制转型。RBI 修订后的认证框架为可使用的认证因素提供了更大的灵活性,不再将短信 OTP 视为唯一合规的第二因素,而是为通行密钥等能够增强安全性、同时降低对易受钓鱼和社工攻击的凭证依赖的技术创造了政策空间。2026 年 4 月 1 日起生效的双因素认证强制要求,进一步推动行业从静态的、基于通信信道传递的认证因素向动态的、设备绑定的认证因素演进。

RBI 的政策转向具有明确的问题导向。传统 OTP 的安全缺陷已被大量安全事件和欺诈数据所证实,监管层认识到仅靠强制要求双因素认证而不限制第二因素的类型,无法从根本上提升支付安全。通行密钥等基于密码学的设备绑定认证因素,能够在满足双因素认证要求的同时,提供比 OTP 更高的安全保证,因此成为监管框架鼓励的技术方向。Zeta 与 Pluxee 在 RuPay 网络上线通行密钥认证,正是在这一政策窗口期内的实践落地。

2.3 RuPay 卡生态的快速扩张

通行密钥认证选择在 RuPay 网络上首发,与 RuPay 在印度卡支付生态中的快速扩张密切相关。数据显示,UPI 关联的 RuPay 信用卡目前占印度信用卡支付交易量的近 38%,而两年前这一比例仅为 10%;RuPay 在整体信用卡市场的份额也从同期的 3% 攀升至 16%。RuPay 卡的快速增长意味着其持卡人基数和交易规模正在迅速扩大,在这一网络上率先部署通行密钥认证,可以在较短时间内覆盖大量用户,积累规模化的实施经验。

RuPay 由 NPCI 运营,作为印度本土卡网络,其在标准制定和技术部署上具有较高的灵活性和决策效率。NPCI 能够直接推动通行密钥认证在 RuPay 网络上的技术适配和规则制定,无需等待国际卡组织的全球标准协调,这为通行密钥的快速落地提供了组织条件。Zeta 作为银行科技平台,具备端到端的支付技术栈实施能力,能够完成从注册、凭证管理、认证编排到交易完成的全流程开发;Pluxee 作为发卡方,拥有大量预付卡持卡人,能够为通行密钥认证提供真实的用户测试场景。三方的能力互补构成了通行密钥在 RuPay 网络落地的实施基础。

3 Zeta-Pluxee 通行密钥认证方案的技术架构

3.1 通行密钥的密码学基础

通行密钥基于 WebAuthn(Web 认证)标准和 FIDO2 协议框架,其核心是公钥密码学。在通行密钥的注册阶段,用户设备生成一对非对称密钥 —— 公钥和私钥,私钥存储在设备的安全硬件(如苹果的 Secure Enclave、安卓的 StrongBox 或通用的可信执行环境)中,公钥注册到服务端。在认证阶段,服务端发送一个随机挑战值,用户设备使用私钥对挑战值进行数字签名,将签名返回服务端,服务端使用存储的公钥验证签名的有效性。整个过程中私钥不离开设备安全硬件,不经过网络传输,服务端不存储任何可被用于冒充用户的秘密。

通行密钥的另一个关键特性是与用户设备的生物识别或设备 PIN 绑定。在使用通行密钥进行认证时,用户需要通过指纹、面部识别或设备 PIN 来解锁设备中的私钥,这意味着即使设备丢失,没有用户的生物特征或 PIN,攻击者也无法使用设备中的通行密钥进行认证。这一设计将 "你拥有的东西"(设备中的私钥)和 "你是谁或你知道的东西"(生物特征或 PIN)两个认证因素整合在一次操作中,在用户体验上表现为单次生物识别即可完成双因素认证。

在支付场景中,通行密钥的认证流程需要与卡网络的授权流程进行编排。Zeta 实施的方案中,通行密钥认证作为在线卡交易的第二因素,替代了传统的短信 OTP 验证步骤。当持卡人在商户页面发起在线支付时,支付网关将交易路由至 RuPay 网络,RuPay 网络调用 Zeta 的认证编排服务,Zeta 服务向持卡人设备发起通行密钥认证请求,持卡人完成生物识别或 PIN 验证后,设备生成认证签名,Zeta 服务验证签名后向 RuPay 网络返回认证成功结果,交易继续进入授权流程。

3.2 一次性注册流程

Zeta 实施的通行密钥注册采用了 "交易即注册" 的融合设计,将通行密钥注册与用户的首次在线交易合并在同一个流程中,以降低注册的心理门槛和操作步骤。具体流程如下:当持卡人在商户结账页面发起 RuPay 卡在线支付时,支付页面提供注册通行密钥的选项。持卡人选择注册后,设备生成通行密钥对并完成设备端的验证(生物识别或 PIN)。随后,系统发送一个一次性短信 OTP,这个 OTP 同时完成两个功能:确认通行密钥的注册有效性,以及完成当前这笔交易的认证。注册完成后,该通行密钥即可用于后续符合条件的交易,无需再使用短信 OTP。

这一设计的巧妙之处在于将注册行为嵌入用户已经在进行的支付流程中,而非要求用户单独前往设置页面完成注册。用户在完成一笔正常支付的同时就完成了通行密钥的注册,不需要额外的操作步骤或跳转。Zeta 披露的数据显示,注册环节平均耗时 7 至 8 秒,完成率达 99%,这一数据表明融合式注册设计在用户体验上是成功的,绝大多数用户能够在不产生明显摩擦的情况下完成注册。

然而,注册环节也是整个通行密钥安全模型中最需要关注的攻击面。注册时使用的一次性 OTP 仍然是通过短信信道传递的,这意味着注册环节本身仍然面临 SIM 劫持和短信拦截的风险。如果攻击者在用户注册通行密钥时截获了注册 OTP,理论上可以在攻击者控制的设备上注册通行密钥,从而将合法用户的账户绑定到攻击者的设备。Zeta 的方案通过将注册 OTP 与当前交易绑定、要求设备端验证等方式增加了攻击难度,但注册环节的安全性仍然是通行密钥部署中需要持续加固的环节。

3.3 后续交易认证流程

注册完成后,后续符合条件的在线交易不再需要短信 OTP。当持卡人使用已注册通行密钥的 RuPay 卡进行在线支付时,支付流程自动调用通行密钥认证。持卡人只需在设备上完成一次生物识别检查 —— 面部识别、指纹或设备 PIN—— 交易即被即时认证,整个过程不涉及任何 OTP 的发送、等待、检索或输入。

这一流程的用户体验优势是显著的。传统 OTP 流程中,用户需要等待短信到达、切换到短信应用查看 OTP、记住或复制 OTP、切回支付页面输入 OTP,这一系列操作不仅耗时,而且容易因短信延迟、用户输入错误等原因导致认证失败或交易放弃。通行密钥认证将这些步骤压缩为一次生物识别操作,用户在支付页面即可完成,无需切换应用或输入任何字符。Zeta 披露的数据显示,通行密钥认证平均耗时 5 至 7 秒,而传统 OTP 流程平均耗时 15 至 25 秒,认证时间缩短约 70%。

从安全角度看,后续交易认证环节是通行密钥安全模型最稳固的部分。认证过程中不传递任何共享秘密,私钥在设备安全硬件中完成签名操作,生物识别或 PIN 确保只有设备的合法持有者才能触发签名。即使攻击者截获了认证过程中的网络流量,也无法获得任何可用于重放或冒充的信息,因为每次认证使用的挑战值都是随机生成的,签名不可重用。

3.4 性能表现与用户体验数据

Zeta 披露的实施数据为评估通行密钥在支付场景中的实际可行性提供了重要的实证参照。认证时间方面,通行密钥认证平均 5 至 7 秒完成,较 OTP 流程的 15 至 25 秒缩短约 70%。这一性能提升不仅改善了用户体验,更具有商业意义:认证时间越短、操作步骤越少,支付过程中的用户放弃率越低,商户的支付完成率和转化率越高。对于高频小额交易场景,认证时间的缩短尤为重要,因为用户对这类交易的耐心阈值更低。

注册完成率方面,Zeta 观察到 99% 的注册完成率。这一数据表明融合式注册设计在用户体验上是成功的,绝大多数用户能够在不产生明显摩擦的情况下完成注册。高注册完成率是通行密钥规模化推广的前提条件,如果注册流程过于复杂或失败率过高,即使认证环节的安全和体验优势再明显,也无法覆盖足够的用户群体。

需要指出的是,这些数据来自 Zeta 与 Pluxee 的单一实施场景,用户群体为 Pluxee 的 RuPay 预付卡持卡人,可能具有特定的人口统计学特征和设备使用习惯。在更广泛的用户群体和不同的发卡机构、商户场景中,通行密钥的认证时间和注册完成率可能存在差异。此外,5 至 7 秒的认证时间包含了设备唤醒、生物识别验证、网络通信等多个环节,实际体验可能因设备性能、网络状况、生物识别成功率等因素而波动。这些数据为通行密钥的可行性提供了积极信号,但规模化推广仍需更多场景和更长周期的验证。

4 通行密钥相对于短信 OTP 的安全优势

4.1 抗钓鱼与抗社会工程学特性

通行密钥最核心的安全优势在于其抗钓鱼特性。传统 OTP 的安全模型中,用户需要将收到的 OTP 输入支付页面,这一输入行为可以被钓鱼攻击利用:攻击者搭建仿冒的支付页面,诱导用户在仿冒页面上输入卡号和 OTP,攻击者获取这些信息后即可在真实支付页面上完成交易。OTP 是一个共享秘密,一旦被用户输入到钓鱼页面,攻击者就可以在短时间内使用它完成认证。

通行密钥从根本上消除了这一攻击向量。通行密钥的认证过程中,用户不需要输入任何可被重复使用的秘密。设备中的私钥对服务端发来的随机挑战值进行签名,签名与挑战值一一对应,不可重用。更重要的是,通行密钥的认证操作与特定的域名(来源)绑定。通行密钥在注册时记录了注册来源的域名信息,在认证时设备会验证当前请求的域名是否与注册时的域名一致,如果用户被诱导到钓鱼网站,钓鱼网站的域名与注册域名不匹配,设备中的通行密钥不会被触发,用户无法在钓鱼页面上完成通行密钥认证。这一域名绑定机制是通行密钥抗钓鱼的技术基石。

反网络钓鱼技术专家芦笛指出,通行密钥的抗钓鱼特性不是通过教育用户 "不要点击可疑链接" 来实现的,而是通过技术机制使得即使在钓鱼页面上也无法完成认证。这一点至关重要,因为用户教育的有效性始终有限,而技术机制的防护是确定性的。从攻击经济学的角度看,当通行密钥成为主流认证方式后,钓鱼攻击的回报率将大幅下降,因为攻击者即使搭建了高度逼真的钓鱼页面,也无法获取用户的认证凭证,这将从根本上改变钓鱼攻击的成本收益比。

4.2 设备绑定与不可导出性

通行密钥的私钥存储在用户设备的安全硬件中,具有不可导出性。这意味着私钥无法被复制到其他设备,无法通过恶意软件从设备中窃取,无法通过网络传输泄露。即使用户的设备被恶意软件感染,只要安全硬件的隔离机制未被突破,私钥仍然安全。这与 OTP 形成鲜明对比:OTP 在到达用户手机后以明文形式存储在短信应用中,可以被短信拦截木马读取和转发;OTP 在用户输入过程中可以被键盘记录器捕获;OTP 在网络传输过程中可以被中间人攻击截获。

设备绑定还意味着通行密钥的使用与物理设备的占有相关联。攻击者要使用用户的通行密钥进行认证,必须物理占有用户的设备,并且能够通过设备的生物识别或 PIN 验证。这将远程网络攻击的门槛提升到了物理攻击的层面,大幅增加了攻击的难度和风险。对于绝大多数网络攻击者而言,物理获取目标用户的设备并绕过其生物识别是不现实的,这使得通行密钥认证的账户被远程接管的概率显著降低。

当然,设备绑定的安全性依赖于设备安全硬件的实现质量。如果设备的安全硬件存在漏洞,或者生物识别系统可以被欺骗,通行密钥的安全性也会受到影响。但总体而言,主流移动设备的安全硬件经过了多年的安全审计和实战检验,其安全强度远高于短信信道和 OTP 输入流程。

4.3 对 CNP 欺诈和拒付的抑制作用

卡未到场(CNP)欺诈是在线卡支付的主要欺诈类型,指持卡人未亲自出示卡片、通过网络或电话完成的交易中发生的欺诈。传统 OTP 认证虽然在一定程度上降低了 CNP 欺诈,但由于 OTP 可被钓鱼和拦截,欺诈者仍然可以通过获取用户的 OTP 来完成欺诈交易。通行密钥的抗钓鱼和不可导出特性,使得欺诈者难以通过网络攻击获取用户的认证能力,从而直接抑制了 CNP 欺诈的发生。

对于发卡机构和商户而言,CNP 欺诈率的降低意味着欺诈损失和拒付成本的下降。拒付(chargeback)是指持卡人对交易提出异议并要求银行撤回付款的行为,CNP 欺诈是拒付的主要原因之一。较高的拒付率不仅带来直接的资金损失,还可能导致商户被支付网络处以罚款或限制,甚至被取消收单资格。通行密钥认证通过降低 CNP 欺诈率,可以间接降低拒付率,为发卡机构和商户带来实际的经济收益。

需要注意的是,通行密钥对 CNP 欺诈的抑制作用是有条件的。只有当交易使用通行密钥进行认证时,抗钓鱼特性才生效;如果用户未注册通行密钥,或交易场景不支持通行密钥认证,仍然需要使用 OTP 等传统方式。因此,通行密钥对整体 CNP 欺诈率的影响取决于其覆盖率 —— 注册并使用通行密钥的持卡人比例越高,整体欺诈率的下降越明显。这也是为什么 Zeta 在设计注册流程时追求高完成率,因为只有足够高的覆盖率才能将通行密钥的安全优势转化为整体欺诈率的实质性下降。

4.4 认证时延缩短与转化率提升

通行密钥的安全优势通常是讨论的重点,但其用户体验优势同样具有重要的安全和商业意义。传统 OTP 流程的多步骤操作和较长等待时间,不仅影响用户体验,还会导致支付过程中的用户放弃。在电商场景中,结账环节的每一个额外步骤都会增加用户放弃交易的概率,OTP 的等待和输入是结账放弃的主要原因之一。通行密钥将认证压缩为一次生物识别操作,显著缩短了认证时间,减少了操作步骤,从而降低了认证相关的交易放弃率,提升了支付完成率和商户转化率。

从安全角度看,更短的认证时间和更少的操作步骤也意味着用户在认证过程中暴露在钓鱼攻击下的时间窗口更短。OTP 流程中,用户需要切换到短信应用查看 OTP,这一过程中用户可能收到仿冒的欺诈短信,或被诱导在错误的页面上输入 OTP。通行密钥认证不需要用户离开支付页面,不需要查看和输入任何字符,用户的注意力始终集中在当前的支付页面上,减少了被分心和诱导的机会。

Zeta 披露的 5 至 7 秒认证时间和 99% 注册完成率,表明通行密钥在支付场景中可以同时实现高安全性和良好的用户体验,打破了 "安全与便捷不可兼得" 的传统认知。这一特性对于通行密钥的规模化推广至关重要,因为如果一项安全技术严重损害用户体验,用户和商户都会有动机绕过或放弃使用它,最终导致安全目标无法实现。

5 实施挑战与局限性

5.1 设备兼容性与用户覆盖

通行密钥的部署依赖于用户设备对 WebAuthn/FIDO2 标准的支持。虽然近年来主流操作系统(iOS、Android、Windows、macOS)和浏览器(Chrome、Safari、Edge、Firefox)都已支持通行密钥,但仍有一定比例的老旧设备和旧版操作系统不支持或不完全支持通行密钥功能。在印度这样的市场中,低端安卓设备的保有量较大,部分设备可能缺乏安全硬件或运行的旧版操作系统不支持通行密钥 API,这部分用户无法使用通行密钥认证,仍然需要依赖 OTP。

设备兼容性问题意味着通行密钥在可预见的未来无法实现 100% 的用户覆盖,支付系统需要同时支持通行密钥和 OTP 两种认证方式,根据用户设备的能力动态选择认证方式。这种双轨制增加了系统的复杂性,也意味着 OTP 的安全风险不会因通行密钥的引入而立即消失,而是会在未覆盖的用户群体中持续存在。

此外,通行密钥的体验在不同设备和平台上存在差异。苹果设备的通行密钥通过 iCloud 钥匙串同步,安卓设备通过 Google 密码管理器同步,不同生态之间的跨平台同步体验尚不完善。用户更换设备或在不同品牌设备之间切换时,通行密钥的迁移和恢复可能遇到问题,影响用户体验和持续使用率。

5.2 注册环节的安全瓶颈

如前文所述,通行密钥的注册环节是整个安全模型中最薄弱的环节。Zeta 的方案中,注册时仍然使用一次性短信 OTP 来确认注册有效性和当前交易,这意味着注册环节本身仍然暴露在 OTP 的安全风险之下。如果攻击者能够截获用户的注册 OTP,理论上可以在攻击者控制的设备上为用户的账户注册通行密钥,从而将合法用户的账户绑定到攻击者的设备。后续交易中,攻击者可以使用自己设备上的通行密钥完成认证,而合法用户可能完全不知情。

注册环节的安全瓶颈是通行密钥部署中一个尚未被完全解决的问题。理论上,可以使用更强的身份验证方式来替代注册 OTP,例如基于银行 App 的推送认证、视频面签、生物识别身份核验等,但这些方式要么增加了注册的操作复杂度,要么依赖额外的基础设施,在大规模推广中存在成本和体验的权衡。Zeta 选择使用 OTP 进行注册确认,是在安全性和用户体验之间的务实折中,但这一折中意味着注册环节仍然是攻击者可以尝试突破的攻击面。

反网络钓鱼技术专家芦笛强调,通行密钥的整体安全性取决于其最薄弱的环节,注册环节如果仍然依赖可被钓鱼的 OTP,那么攻击者就会将攻击重点从认证环节转移到注册环节。支付机构在部署通行密钥时,应当对注册环节实施额外的安全控制,例如注册时的设备风险评估、注册后的通知确认、异常注册行为的检测和拦截等,以降低注册环节被攻击的风险。

5.3 密钥丢失与账户恢复

通行密钥的设备绑定特性在提升安全性的同时,也带来了密钥丢失后的账户恢复问题。如果用户的设备丢失、损坏或被盗,而用户没有在其他设备上同步通行密钥,那么用户将无法使用通行密钥进行认证。虽然用户通常可以通过其他方式(如 OTP、客服验证)恢复账户访问,但恢复过程本身可能成为安全攻击的目标。

账户恢复是身份认证系统中公认的难题。恢复流程需要在用户便利性和安全性之间取得平衡:如果恢复流程过于简单,攻击者可以通过社会工程学攻击绕过通行密钥的保护,直接通过恢复流程获取账户访问权;如果恢复流程过于严格,合法用户在设备丢失后可能面临长时间的账户锁定,严重影响用户体验。

在支付场景中,账户恢复的安全性要求更高,因为支付账户直接关联用户的资金。通行密钥部署后,发卡机构需要设计安全且可用的账户恢复机制,例如通过银行 App 的设备绑定进行身份验证、通过客服热线进行多维度身份核验、通过备用通行密钥设备进行恢复等。同时,发卡机构应当在用户注册通行密钥时引导用户完成多设备同步或设置恢复选项,以降低设备丢失后的恢复难度。

5.4 多设备同步与跨平台体验

现代用户通常拥有多台设备(手机、平板、电脑),希望在所有设备上都能使用通行密钥认证。通行密钥的多设备同步依赖于操作系统厂商提供的云同步服务:苹果的通行密钥通过 iCloud 钥匙串在苹果设备之间同步,安卓的通行密钥通过 Google 密码管理器在安卓设备之间同步。但在跨平台场景中(例如用户有一部安卓手机和一台 Windows 电脑,或一部 iPhone 和一台安卓平板),通行密钥的同步体验尚不完善,用户可能需要在每台设备上单独注册通行密钥,或者使用 QR 码等方式进行跨设备认证。

多设备同步的不完善不仅影响用户体验,还可能导致安全问题。如果用户因为同步困难而在多台设备上重复注册通行密钥,每一次注册都是一次安全暴露;如果用户因为某台设备不支持通行密钥而继续使用 OTP,那么 OTP 的安全风险仍然存在。跨平台通行密钥同步的标准化和体验优化,是通行密钥从早期采用走向主流普及需要解决的重要问题。

迪妙网安研究团队在对通行密钥跨平台同步的研究中发现,不同操作系统厂商之间的通行密钥同步机制存在互操作性差异,部分同步方案在安全强度和用户体验上存在权衡。支付机构在部署通行密钥时,应当对不同设备组合下的同步和认证体验进行充分测试,并为用户提供清晰的指引,避免因同步问题导致用户放弃使用通行密钥或遭遇安全风险。

6 推广路径与生态协同

6.1 发卡机构侧的系统改造

通行密钥的规模化推广首先需要发卡机构完成系统侧的改造。发卡机构需要在其认证系统中增加对 WebAuthn/FIDO2 协议的支持,实现通行密钥的注册、存储、验证和管理功能。这包括公钥的安全存储、认证挑战值的生成和验证、通行密钥与用户账户的绑定关系管理、通行密钥的撤销和更新机制等。对于使用第三方银行科技平台(如 Zeta)的发卡机构,系统改造可以通过平台的能力升级快速完成;对于自建系统的大型银行,则需要投入专门的开发和测试资源。

除了技术系统改造,发卡机构还需要制定通行密钥相关的业务规则和风控策略。这包括:哪些交易场景支持通行密钥认证、通行密钥认证的交易限额如何设定、注册环节的风控规则、异常通行密钥使用行为的检测和响应、通行密钥用户的欺诈责任划分等。这些业务规则需要在安全和体验之间取得平衡,并随着实施数据的积累持续优化。

发卡机构还需要为客户服务团队提供通行密钥相关的培训和支持工具。当用户遇到通行密钥注册失败、认证异常、设备丢失后恢复等问题时,客服团队需要能够准确理解问题并提供有效的解决方案。客服支持的质量直接影响用户对通行密钥的信任度和持续使用率。

6.2 商户侧的受理适配

通行密钥认证的用户体验不仅取决于发卡机构和卡网络的实现,还取决于商户结账页面的适配。商户的支付页面需要支持调用通行密钥认证的 API,正确处理通行密钥认证的请求和响应,在用户设备不支持通行密钥时优雅地回退到 OTP 认证。对于使用第三方支付网关的商户,通行密钥的支持取决于支付网关的能力升级;对于自建支付系统的大型电商,则需要专门的前端和后端开发。

商户侧的适配还包括用户界面的设计。通行密钥认证的提示需要清晰、直观,让用户理解需要进行生物识别或 PIN 验证来完成支付,而不是让用户感到困惑。注册通行密钥的引导也需要在商户页面上自然地呈现,避免给用户造成额外的心理负担。商户页面上的通行密钥标识和说明,可以帮助用户建立对这一新型认证方式的认知和信任。

从商户的动机来看,通行密钥带来的欺诈率下降和转化率提升是推动其适配的主要经济动力。但对于中小商户而言,系统改造的成本和技术能力可能是障碍。支付网关和收单机构在通行密钥的商户推广中可以发挥关键作用,通过将通行密钥支持内置到支付网关产品中,降低商户的适配成本和技术门槛。

6.3 网络侧的标准协同

卡网络在通行密钥的推广中扮演着标准制定和规则协调的角色。NPCI 作为 RuPay 网络的运营方,需要制定通行密钥在 RuPay 卡支付中的技术规范和业务规则,包括通行密钥认证的消息格式、交易流程中的认证编排、通行密钥认证交易的清算和结算规则、欺诈责任划分等。这些标准需要与发卡机构、收单机构、商户、支付网关等各方的系统实现保持一致,确保端到端的互操作性。

卡网络还需要在通行密钥认证与现有双因素认证框架之间建立衔接。RBI 的双因素认证要求需要明确通行密钥认证是否满足合规要求,以及在哪些条件下满足。NPCI 与 RBI 之间的政策协调,对于通行密钥在监管框架下的合法部署至关重要。Zeta 与 Pluxee 在 RuPay 网络上的先行实施,也为 NPCI 完善通行密钥相关标准提供了实践反馈。

在国际层面,通行密钥在卡支付中的应用还需要与国际卡组织(Visa、Mastercard)的标准和全球电商的受理环境进行协调。虽然 Zeta 的实施目前限于 RuPay 网络,但随着通行密钥的推广,跨境交易和国际卡组织的兼容将成为需要考虑的问题。

6.4 用户教育与习惯养成

任何新型认证方式的成功推广,最终都取决于用户的接受度和使用习惯。通行密钥对于大多数用户而言是一个陌生的概念,用户可能不理解 "通行密钥" 是什么、为什么需要注册、它与密码或 OTP 有什么区别。发卡机构和卡网络需要通过清晰、简洁的用户教育,帮助用户建立对通行密钥的认知和信任。

用户教育的重点不应是技术原理的讲解,而是使用体验和安全收益的传达。用户需要理解的是:注册通行密钥后,支付时不再需要等待和输入 OTP,只需一次指纹或面部识别即可完成;通行密钥比 OTP 更安全,因为它不会被骗子通过短信骗取;通行密钥只在用户自己的设备上生效,别人即使知道用户的密码也无法使用。这些信息需要在注册流程中以自然的方式呈现,而不是以冗长的免责声明或技术文档的形式出现。

习惯养成需要时间和正向反馈。当用户多次体验到通行密钥认证的便捷性后,会逐渐形成使用习惯,并对需要输入 OTP 的交易产生不适应感,这种不适应感反过来会推动用户在更多场景中使用和注册通行密钥。发卡机构可以通过激励机制(如通行密钥认证交易的积分奖励、优先客服等)加速用户习惯的养成。

迪妙安全研究团队在对新型认证方式用户接受度的研究中发现,用户对新型认证方式的信任建立在三个因素之上:首次使用的流畅体验、使用过程中的稳定可靠性、出现问题时的有效支持。通行密钥的推广需要在这三个方面都达到较高的水准,才能实现从早期采用者到主流用户的跨越。

7 结语

Zeta 与 Pluxee 在 RuPay 网络上上线通行密钥认证,标志着支付认证从基于短信信道传递共享秘密的 OTP 模式,向基于设备绑定密码学的通行密钥模式迈出了实质性的一步。这一转型的驱动力来自印度数字支付欺诈的严峻态势、RBI 对强认证机制的政策推动,以及 RuPay 卡生态的快速扩张所创造的规模化实施条件。Zeta 披露的实施数据 —— 认证时间 5 至 7 秒、较 OTP 缩短约 70%、注册完成率 99%—— 表明通行密钥在支付场景中可以同时实现高安全性和良好用户体验,打破了安全与便捷不可兼得的传统困境。

通行密钥相对于短信 OTP 的安全优势是多维度的:抗钓鱼特性源于认证过程中不存在可被重复使用的共享秘密,且认证操作与域名绑定使得钓鱼页面无法触发认证;设备绑定和私钥不可导出性将远程网络攻击的门槛提升到物理攻击层面;对 CNP 欺诈和拒付的抑制作用为发卡机构和商户带来实际经济收益;认证时延的缩短则在提升用户体验的同时减少了认证过程中的攻击暴露窗口。

然而,通行密钥并非万能方案。设备兼容性的限制意味着在可预见的未来需要通行密钥与 OTP 的双轨制运行;注册环节对 OTP 的依赖使得注册成为整个安全模型中最薄弱的环节;密钥丢失后的账户恢复是安全性与可用性之间的持久难题;多设备同步和跨平台体验的不完善可能影响用户的持续使用率。这些挑战决定了通行密钥替代 OTP 将是一个渐进过程,而非一次性的技术切换。

反网络钓鱼技术专家芦笛指出,通行密钥的真正价值不在于它是一个更复杂的认证技术,而在于它从根本上改变了钓鱼攻击的成本收益结构 —— 当用户不再需要输入任何可被钓鱼的秘密时,钓鱼攻击的回报率将大幅下降,攻击者将不得不转向更困难、更低效的攻击方式。但这一价值的实现前提是通行密钥达到足够高的覆盖率,而覆盖率的提升需要发卡机构系统改造、商户受理适配、卡网络标准协同、用户教育习惯养成的全生态配合。

迪妙网络空间安全学院研究团队的跟踪研究表明,支付机构在评估通行密钥部署时,应当避免将视野局限于认证环节本身的密码学强度,而应将设备覆盖率、注册环节安全、密钥恢复机制、跨平台同步能力、商户适配进度纳入整体安全架构的评估框架。通行密钥的安全增益是系统性的,只有当整个生态的各个环节都达到相应的安全水准时,通行密钥的潜力才能充分发挥。

本文不认为通行密钥将在短期内完全取代 OTP,也不认为通行密钥解决了支付认证的所有安全问题。支付认证的演进是一个持续的过程,通行密钥是这一过程中的重要一步,但不是终点。未来,随着设备能力的提升、标准的完善和用户习惯的养成,通行密钥的覆盖率将逐步提高,OTP 的使用范围将逐步缩小,但二者在较长时期内仍将共存。支付生态的各方应当以开放和务实的态度推进通行密钥的部署,在安全增益与用户覆盖之间寻求渐进式平衡,推动支付认证从脆弱的共享秘密模式向坚韧的密码学信任模式稳步转型。

编辑:芦笛(公共互联网反网络钓鱼工作组)

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

目录
相关文章
|
7天前
|
人工智能 API 内存技术
刚刚 DeepSeek V4.1 Flash 开启内测,1 分钟教你用上!
刚刚 DeepSeek 内测群发布了 DeepSeek V4.1 Flash 中间版本内测的消息,这次的模型采用了新的结构,原生支持多模态、能力更强、速度更快、且成本更低。
1814 13
|
7天前
|
人工智能 自然语言处理 安全
阿里云千问办公 QwenWork详细介绍:产品核心能力、典型场景、价格及常见问题解答
千问办公是阿里云推出的一站式AI办公平台,主打"不止于对话,更注重交付",依托通义千问旗舰大模型,用户一句话即可完成数据分析、PPT生成、视频剪辑等复杂任务,直接输出可用成果。产品深度打通钉钉生态与企业OA,覆盖桌面端、网页端,提供企业标准版198元/人/月等多档订阅方案,新用户注册即赠2000积分,适配工程师、HR、财务等多职业办公场景,成为能动手干活的"全能AI同事"。
|
13天前
|
网络协议 Linux iOS开发
【2026实测】Wireshark下载+安装+汉化+使用教程(图文版,巨详细)
Wireshark 是一款免费开源的网络协议分析工具,可实时捕获、解析并可视化数据包,助你诊断网络故障、分析通信协议(如HTTP、DNS、TCP等)。支持Windows/macOS/Linux,含中文界面,新手入门便捷。(239字)
|
12天前
|
人工智能 运维 BI
阿里云千问办公QwenWork深度解析:基于Qwen3.8,六大核心能力重构企业全自动化工作流与计费选型指南
传统AI办公工具大多停留在对话问答、文档摘要、简单文案生成层面,只能完成单点碎片化任务,无法自主拆解复杂业务流程,很难串联多工具、多文档、外部业务系统完成端到端完整工作交付。很多企业在落地AI办公的时候,需要组合多款不同工具,来回切换界面,手动复制粘贴中间结果,智能化改造落地门槛居高不下。千问办公QwenWork是整合多款智能体产品能力打造的一体化企业办公智能体平台,底层基座依托Qwen3.8大模型,打通桌面端Agent、云端Agent、企业协同Agent三种运行形态,不再局限简单问答,接收业务目标之后自主拆解任务步骤,调用各类工具,处理文档、表格、浏览器自动化、数据查询,直接输出可交付的办公
1647 3
|
7天前
|
人工智能
千问办公官网入口:阿里AI办公QwenWork产品页和免费网页端链接
千问办公官网含两大入口:一是网页端(qwenwork.cn),即开即用,支持浏览器直接访问;二是阿里云产品页 https://t.aliyun.com/U/JNKJuO 提供免费/付费版详情、功能介绍及使用指南。
|
9天前
|
SQL 人工智能 前端开发
QoderWake 1.0 正式发布:从桌面里的 Agent,到工作现场的数字员工
QoderWake v1.0正式发布:企业级数字员工团队平台。支持“一句话建岗”,预置10类特训岗位;Waker常驻钉钉/飞书群,@即响应、自动协作、跨任务记忆;具备定时/事件/API多触发方式与统一任务看板;已沉淀27.6万条记忆、12.3万项技能,助力组织实现人机协同增效。
790 2
|
6天前
|
缓存 测试技术 API
DeepSeek V4.1 Flash 内测接入:改个模型名即可调用(附代码)
DeepSeek V4.1 Flash 内测不用申请,base_url 不变、改个模型名就能调,9/10 到期。本文讲清接入、计费限流与多模态注意点。
812 0
DeepSeek V4.1 Flash 内测接入:改个模型名即可调用(附代码)
|
14天前
|
缓存 数据可视化 开发工具
DeepSeek Harness 怎么更新?dsh 更新完整指南:更新本体(npx、npm、源码)与更新插件两种方式
DeepSeek Harness 的更新分两层:本体更新(npx 自动最新、npm update -g、源码 git pull)与插件更新(插件市场点更新、命令行覆盖安装)。本文按「准备 → 更新本体 → 更新插件 → 更新后检查」四步走,覆盖新手常见疑问。
1607 1
DeepSeek Harness 怎么更新?dsh 更新完整指南:更新本体(npx、npm、源码)与更新插件两种方式
|
21天前
|
人工智能 自然语言处理 安全
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
本文聚焦阿里云2026年推出的三款自研AI办公产品,清晰拆解千问办公、Qoder Teams、Qoder CN的差异化定位与能力边界:千问办公主打职场全场景提效,支持自然语言指令一键完成PPT生成、数据分析等高频办公任务;Qoder Teams面向程序员团队,深度整合AI代码生成、团队协同与企业知识库能力;Qoder CN则专为金融、政务等强合规场景打造,实现数据不出境与VPC私有化部署。文章同步给出分场景选型指南与最新活动定价,帮助不同类型的企业按需组合产品,实现业务岗、研发岗与强合规场景的AI能力全覆盖。
3989 5
阿里云千问办公、Qoder Teams、Qoder CN区别与选择指南:模型能力、适用场景与最新活动参考
|
12天前
|
人工智能 自然语言处理 安全
阿里云AI数智鉴密:AI 生成内容如何拿到一张"防篡改的身份证"
隐形水印 + C2PA签名:让AI生成内容“持证上岗”。
1156 0