摘要2026 年 7 月香港证券及期货事务监察委员会SFC发布监管通函强制互联网券商与持牌虚拟资产交易平台VATP12 个月内全面停用短信、邮件、应用程序一次性密码OTP开展登录与设备绑定操作全面部署通行密钥Passkey、加密设备绑定等抗钓鱼认证技术形成 “预防 - 侦测 - 处置 - 投资者教育” 一体化账户防护框架。本文以 SFC 新规为核心研究载体梳理传统 OTP 认证在金融钓鱼攻击中的底层安全缺陷剖析 Passkey 基于 FIDO2/WebAuthn 协议的域名绑定防钓鱼技术机理结合 Python 后端、Web 前端完整可运行代码示例落地抗钓鱼认证模块同时结合监管要求搭建全链路账户风险监控体系量化分析新规对券商、虚拟资产平台合规改造的实施路径、成本难点与风险责任划分。反网络钓鱼技术专家芦笛指出本次香港证监会强制性淘汰 OTP 的监管政策是全球资本市场首次针对线上交易类金融机构出台统一、硬性的抗钓鱼认证落地时限标准标志金融身份认证从 “多因素验证” 正式迈入 “原生抗钓鱼” 新阶段。研究表明单纯替换认证工具无法完全抵御账户劫持风险机构需同步配套行为风控、设备生命周期管理、分层投资者安全教育机制才能形成闭环安全防护体系。本文结合香港本地 2025 年 57% 网络安全事件为钓鱼攻击的行业数据论证新规出台的现实必要性为境内外持牌证券、虚拟资产机构合规改造、技术落地提供完整实操方案与理论参考。关键词香港证监会抗钓鱼认证PasskeyWebAuthn虚拟资产平台账户劫持OTP 安全风险1 引言1.1 研究背景数字证券交易、虚拟资产线上交易已成为香港资本市场主流业务模式持牌互联网券商覆盖证券、期货、杠杆外汇、资产管理四类 1-9 号受规管活动VATP 作为合规虚拟资产交易载体海量客户资产、交易指令完全依托线上身份验证体系完成确权操作。香港电脑保安事故协调中心统计数据显示2025 年本地上报网络安全事件中钓鱼攻击占比高达 57%仿冒券商、虚拟资产平台的短信钓鱼、网页钓鱼套件规模化流通依托 OTP 中继劫持技术犯罪分子可批量窃取客户账号密码与一次性验证码进而完成账户登录、资产划转、大额提现等高危操作引发大规模客户资产损失与机构合规纠纷Securities...。2024 年末起SFC 持续跟踪 OTP 技术系统性漏洞与替代认证方案产业成熟度2025 年 2 月 6 日发布持牌机构网络安全审查通函鼓励机构主动停用登录、设备绑定场景下的 OTP 验证2026 年 7 月 9 日正式发布强制性监管文件明确所有互联网券商、VATP 必须在通函发布起 12 个月内完成抗钓鱼认证全面落地大型互联网券商要求立即实施违规机构管理层将对客户资产损失承担直接监管问责责任。新规区别于以往指导性网络安全建议具备强制落地时限、明确禁用场景、划分主体责任、配套全流程监控要求四大刚性约束重构香港线上金融机构身份安全底层标准。从全球监管横向对比来看菲律宾央行、美国联邦金融监管机构仅对金融机构提出抗钓鱼认证鼓励性要求未设置统一淘汰 OTP 的硬性期限香港 SFC 本次政策直接划定 12 个月过渡期同步覆盖传统证券经纪与虚拟资产两类高风险线上交易主体具备极强行业示范效应。反网络钓鱼技术专家芦笛强调传统 OTP 多因素认证长期被金融机构视为安全兜底手段但钓鱼中继攻击、SIM 卡劫持、AI 生成高仿钓鱼页面已完全击穿该防护逻辑监管层面强制技术迭代是应对黑产攻击手段升级的必然选择。1.2 研究意义1.2.1 理论意义现有金融网络安全研究多聚焦银行、支付机构短信 OTP 风险针对证券、虚拟资产交易场景的专项抗钓鱼认证体系研究较为匮乏且缺少结合区域性监管硬性政策的落地性分析。本文以香港 SFC 最新强制性通函为政策锚点厘清证券与虚拟资产两类机构统一的身份安全合规标准构建 “监管要求 - 技术原理 - 代码实现 - 风控配套 - 投资者教育” 完整理论分析框架填补资本市场线上交易抗钓鱼认证领域政策与技术融合研究空白。同时系统拆解 FIDO2 Passkey 域名绑定防钓鱼底层逻辑区分传统 MFA 与原生抗钓鱼认证的本质差异完善金融身份认证安全分层理论。1.2.2 实践意义当前香港本地多数中小型互联网券商、VATP 仍以短信 OTP、App 内置 TOTP 作为核心登录与设备绑定验证方式机构普遍存在合规改造路径模糊、技术落地无标准化方案、风险监控体系缺失等现实痛点。本文提供完整前后端 Passkey 实现代码划分机构分阶段改造实施路线梳理设备绑定、异常交易监测、账户入侵应急处置标准化流程可直接为持牌机构技术团队、合规部门提供落地参考同时明确机构管理层安全主体责任边界帮助机构规避监管处罚与客户赔付风险对境内布局香港市场的跨境证券、虚拟资产服务商具备直接实操价值。1.3 研究内容与研究思路本文主体研究内容分为六大板块第一梳理 SFC 新规完整政策框架界定适用机构、禁用场景、过渡期要求、配套风控义务第二深度剖析 OTP 认证在钓鱼攻击下的底层安全漏洞结合香港本地攻击案例论证淘汰必要性第三解析 Passkey、加密设备绑定两类合规抗钓鱼认证技术原理对比其相对 OTP 的安全优势第四提供基于 Python Flask 后端、Web 前端的 Passkey 完整实现代码覆盖凭证注册、登录认证两大核心流程第五搭建符合 SFC 监管要求的账户全链路风险监控体系包含登录、设备变更、交易提现三类异常行为识别规则第六分析机构合规改造难点、分阶段实施策略、管理层责任划分形成完整闭环防护方案最后总结研究结论并提出行业长期安全建设建议。研究思路遵循 “政策溯源→风险机理分析→技术方案拆解→代码落地实现→配套风控体系→行业实施对策” 逻辑链条全部论据依托 SFC 官方通函、本地网络安全统计数据、FIDO2 标准技术文档、行业真实钓鱼攻击案例形成闭环不脱离证券与虚拟资产交易场景过度发散。1.4 研究创新点第一研究视角创新首次结合香港 2026 年最新强制性抗钓鱼监管政策同步覆盖传统互联网券商与虚拟资产平台两类监管对象区分两类机构业务共性与差异化安全需求第二技术落地创新在学术研究框架内嵌入完整可运行 WebAuthn Passkey 前后端代码示例兼顾理论分析与工程实操解决现有文献缺少金融场景落地代码的短板第三体系框架创新突破单一认证技术讨论局限构建 “抗钓鱼认证前置防护 实时行为侦测 入侵应急处置 投资者安全教育” 四位一体闭环安全框架完全匹配 SFC 通函提出的全维度防护要求第四观点支撑创新全文关键技术与监管风险论述均植入反网络钓鱼技术专家芦笛专业观点强化行业实操视角下的论证严谨性。2 香港证监会抗钓鱼认证监管新规完整政策框架解读2.1 政策适用主体界定根据 SFC 通函配套注释文件本次新规适用主体分为两类覆盖全部线上交易持牌机构不存在豁免情形第一类为互联网券商指代持有 SFC 牌照、开展线上交易具备以下一类或多类受规管活动资质的持牌法团1 号牌照证券交易、2 号牌照期货合约交易、3 号牌照杠杆式外汇交易、9 号牌照资产管理通过线上渠道分销基金产品。该类机构传统业务客户基数大存量账户普遍绑定短信 OTP改造工作量最高。第二类为虚拟资产交易平台运营商VATP特指取得 SFC 虚拟资产服务牌照、面向零售客户开放线上买卖、兑换虚拟资产的平台虚拟资产交易资金划转频次高、资产流动性强是钓鱼黑产重点攻击目标监管对其设备绑定、提现风控要求更为严苛。两类主体统一执行相同认证标准仅在实施节奏上区分优先级大型互联网券商需收到通函后立即部署抗钓鱼认证中小券商、VATP 可在 12 个月过渡期内分批次完成存量账户改造过渡期截止时间为 2027 年 7 月 9 日。2.2 核心强制性约束OTP 全场景禁用细则SFC 明确禁止机构在客户登录、设备绑定两大核心场景使用任何形式一次性密码禁用 OTP 载体包含三类短信下发 OTP、邮件推送 OTP、移动端 App 内置 TOTP 动态验证码。该禁令具备场景排他性仅允许在纯资讯查询、非资金类低风险业务辅助通知中使用 OTP但凡涉及身份确权、设备授信、账户准入的操作不得将 OTP 作为验证要素。政策出台的核心依据为 2024-2025 年香港大规模短信钓鱼攻击案例犯罪分子批量发送仿券商、VATP 官方短信内嵌高仿钓鱼网站链接诱导客户输入账号密码后实时索要短信 OTP钓鱼页面内置 JS 中继脚本将客户提交的验证码同步传输至攻击者后台攻击者同步在官方平台完成登录全程无需破解密码仅依靠客户主动泄露 OTP 即可劫持账户。反网络钓鱼技术专家芦笛指出OTP 的设计逻辑建立在 “验证码仅客户单方持有” 的理想化假设但社交工程钓鱼完全打破该假设OTP 无法验证访问页面的真实域名是其无法抵御钓鱼攻击的底层缺陷。2.3 监管认可的合规抗钓鱼认证方案SFC 在通函中明确两类具备原生防钓鱼能力的认证方式机构可单独或组合部署无强制单一技术要求2.3.1 Passkey通行密钥基于 FIDO2/WebAuthn 国际标准构建无密码认证体系客户端设备生成非对称密钥对私钥永久存储于设备安全加密区域手机安全隔区、电脑 TPM 芯片永不外传公钥上传至机构服务端与客户账户绑定。认证时设备强制校验当前访问网站域名与注册时记录的服务商标识RP ID钓鱼网站域名与官方域名不匹配时设备直接拒绝签名从底层阻断钓鱼中继攻击是当前安全等级最高的合规方案。2.3.2 加密验证绑定设备机构为客户终端设备生成唯一加密设备指纹存储设备硬件唯一标识、系统签名、证书信息设备与账户完成加密绑定。客户登录时服务端校验设备加密指纹完整性同时结合本地生物识别指纹、面容完成二次核验设备指纹与域名强绑定仿冒网站无法获取合法设备加密凭证无法绕过验证。监管要求单个客户绑定设备数量原则上不超过 3 台降低多设备泄露风险。硬件安全密钥FIDO UKey属于加密绑定设备的细分形态适用于高净值客户、大额交易账户机构可作为增值安全选项向客户开放。2.4 配套强制性风控、应急与投资者教育义务新规并非仅替换登录验证工具而是要求机构搭建全生命周期账户安全管控体系四项配套措施为硬性合规要求未落地将被认定为内控缺失实时可疑活动监测体系覆盖异地陌生设备登录、新设备绑定、短时间多笔大额提现、超出历史交易规模的异常下单、频繁密码重置等风险行为系统自动生成风险工单账户事件多渠道通知机制新设备登录、Passkey 新增 / 注销、大额资产划转、密码修改等高风险操作同步通过 App 推送、邮件、短信三重渠道告知客户网络入侵快速响应流程建立 7×24 小时安全处置团队收到账户劫持预警后可一键冻结账户交易、提现权限同步留存完整审计日志用于监管报备与案件追溯常态化客户风险警示定期推送钓鱼攻击新型手法案例客户登录首页弹窗提醒官方渠道辨别方式限制客户通过第三方链接直接跳转登录页面。2.5 机构管理层主体问责机制SFC 在通函中明确责任划分互联网券商、VATP 高级管理层为客户账户资产安全第一责任人若因机构未按期落地抗钓鱼认证、风控监测体系缺失、安全流程存在漏洞导致客户资产被盗监管机构将直接追究管理层合规责任同时机构需承担客户全部资产损失赔付。该条款大幅提升机构安全改造动力区别于以往仅处罚机构主体的监管模式倒逼管理层主动投入网络安全技术资源。3 传统 OTP 认证抵御钓鱼攻击的底层安全缺陷分析3.1 OTP 认证基础工作逻辑短信、邮件、App TOTP 三类一次性密码工作逻辑具备统一底层架构机构服务端基于时间或随机数生成短期有效验证码通过独立通信渠道下发至客户终端客户登录或设备绑定时在页面输入账号密码 收到的 OTP 字符串服务端校验验证码一致性后完成身份授信。其安全设计依赖 “双渠道隔离” 假设账号密码传输渠道网页 / App与 OTP 下发渠道短信 / 邮件相互独立攻击者无法同时控制两条渠道获取完整验证要素。但 2024 年后规模化钓鱼黑产彻底打破该隔离假设OTP 多因素防护逻辑完全失效结合香港本地攻击场景缺陷分为四大维度。3.2 社交工程钓鱼中继攻击最主流风险仿冒官方钓鱼网站是香港 2025 年占比最高的攻击手段攻击链路完整流程如下第一步攻击者搭建视觉、交互逻辑与券商 / VATP 官网完全一致的钓鱼站点域名仅存在细微字符篡改字母替换、增加数字后缀第二步批量发送仿冒客服、监管核查短信诱导客户点击恶意链接跳转钓鱼页面第三步客户在钓鱼页面输入账号、静态密码页面内嵌实时上传脚本将账号密码同步发送至攻击者后台第四步攻击者同步打开机构真实官方登录页面填入窃取的账号密码触发机构向客户手机下发 OTP第五步钓鱼页面弹窗提示 “需输入验证码完成账户核验否则账户冻结”客户主动提交短信 OTP脚本同步转发至攻击者第六步攻击者使用窃取的账号 OTP 在官方平台完成登录接管账户操作权限。反网络钓鱼技术专家芦笛强调该攻击模式的核心漏洞在于 OTP 无域名校验机制验证码本身不携带访问站点身份信息无论客户在钓鱼网站还是官方网站输入服务端仅校验验证码字符串有效性无法区分验证请求来源攻击者可无缝中继全部验证要素。3.3 通信渠道劫持风险3.3.1 SIM 卡劫持SIM Swap攻击者通过黑市收集客户姓名、身份证、开户手机号等开户信息伪装客户向运营商申请手机号携号转网将目标号码转移至攻击者控制的 SIM 卡所有短信 OTP 直接下发至攻击者终端无需诱导客户主动泄露即可获取验证码多用于高净值虚拟资产账户定向攻击。3.3.2 通信链路抓包与邮件劫持短信传输早期无端到端加密运营商网关可抓取明文短信内容即使加密 RCS 短信攻击者可通过恶意木马植入客户手机后台静默读取短信收件箱全部 OTP。邮件 OTP 风险更高邮箱一旦被撞库破解历史、实时全部验证码均可被批量导出。3.4 TOTP 应用验证码的绕过漏洞机构自研 App 或第三方验证器生成的时间型 TOTP 验证码常被攻击者通过恶意移动端木马窃取仿冒金融 App 获取手机系统读取剪贴板、通知栏权限客户复制 TOTP 验证码瞬间木马自动上传至攻击者服务器同时钓鱼页面可诱导客户导出 TOTP 密钥种子攻击者永久生成有效验证码实现长期账户劫持。3.5 时效性与业务可用性缺陷从业务运营角度OTP 存在天然短板网络延迟、运营商故障会导致验证码下发超时客户多次重发验证码造成服务端拥堵验证码有效期通常 5-15 分钟窗口期内攻击者均可完成中继劫持无会话绑定特性单次泄露长期有效。对比 Passkey 单次认证单次挑战、密钥与域名永久绑定的设计OTP 无论安全层面还是使用稳定性均无法满足线上交易高安全标准。3.6 香港本地真实损失数据佐证风险2025 年香港证监会收到券商、VATP 客户钓鱼欺诈投诉超 2100 起全部案件均依托 OTP 漏洞完成账户接管涉案总金额超 3 亿港元虚拟资产平台单起最高损失达 1200 万港元犯罪分子劫持账户后直接划转虚拟资产至海外匿名钱包资产难以追回。正是基于大规模真实损失案例SFC 判定 OTP 技术已无法适配当前黑产攻击水平出台强制性淘汰政策。4 抗钓鱼认证核心技术 PasskeyFIDO2/WebAuthn技术机理与安全优势4.1 FIDO2/WebAuthn 标准体系架构Passkey 依托 FIDO 联盟制定的 WebAuthn 网页认证标准分为两大核心组件客户端验证器Authenticator手机、电脑 TPM、硬件 UKey、依赖方服务端Relying Party券商 / VATP 交易系统全程采用非对称加密算法完成身份校验摒弃静态密码与一次性验证码。整套标准原生内置域名绑定Origin Binding防钓鱼机制是 SFC 唯一明确推荐优先落地的认证方案。完整流程分为两大阶段账户注册设备绑定生成 Passkey 凭证、登录认证设备签名挑战完成身份核验。4.2 Passkey 注册阶段底层逻辑用户发起设备绑定申请服务端RP生成全局唯一随机挑战 Challenge、服务商标识 RP ID机构官方域名、用户唯一标识下发至前端页面前端调用浏览器标准 API navigator.credentials.create()调用本地设备安全隔区生成一对加密密钥私钥存储于设备加密芯片不可导出、不可复制公钥与凭证 ID 返回前端设备在生成凭证时自动记录当前页面域名Origin永久绑定至该组公私钥若后续在其他域名发起认证设备直接拒绝签名前端将公钥、凭证 ID、设备签名数据回传服务端服务端校验 Challenge 完整性、域名合法性校验通过后将公钥、凭证 ID 与客户账户绑定存入数据库注册完成该设备生成唯一 Passkey完成监管要求的加密设备绑定操作。4.3 Passkey 登录认证阶段底层逻辑用户访问机构官方登录页输入账户名触发 Passkey 登录流程服务端生成全新一次性随机 Challenge绑定本机 RP ID 下发前端前端调用navigator.credentials.get()唤起本地 Passkey 验证器设备首先校验当前页面域名是否与注册时绑定域名一致域名匹配通过后触发客户本地生物识别指纹 / 面容 / PIN 码完成用户核验设备使用本地安全隔区内私钥对服务端下发的 Challenge 进行数字签名签名结果、凭证 ID 回传服务端服务端调取数据库存储的对应公钥验证签名有效性签名校验成功且域名匹配无误系统判定身份合法完成登录任意一项校验失败直接拒绝登录无绕过空间。4.4 Passkey 原生抗钓鱼核心机制域名绑定Origin Binding反网络钓鱼技术专家芦笛指出域名绑定是 Passkey 区别于所有 OTP、传统 MFA 的核心安全壁垒也是 SFC 强制推广该技术的根本原因。OTP 无法识别访问页面域名验证码仅为独立字符串而 Passkey 凭证生成时已固化注册站点域名设备本地完成域名校验校验逻辑运行于客户端加密硬件攻击者无法篡改、无法伪造。即使攻击者搭建高度高仿钓鱼网站其域名与机构官方 RP ID 不匹配本地设备直接终止认证流程不存在验证码中继泄露的可能性从底层消除钓鱼攻击入口。4.5 Passkey 相对 OTP 的全方位安全优势对比表格对比维度 短信 / 邮件 / App OTP Passkey 抗钓鱼认证钓鱼抵御能力 无域名校验极易被中继劫持 本地域名绑定钓鱼站点直接拦截密钥存储位置 验证码明文传输、存储于通信通道 私钥存设备安全芯片永不外传攻击门槛 仅需诱导用户主动提交验证码 攻击者需物理持有客户绑定设备并通过生物识别会话唯一性 验证码短时复用多站点通用 每次认证生成独立挑战单次有效SIM 劫持风险 完全暴露手机号被盗即失守 与手机号无绑定不受运营商劫持影响监管合规匹配度 SFC 明令登录、设备绑定场景禁用 监管认可首选合规方案5 基于 WebAuthn 的 Passkey 完整工程代码实现Python 后端 Web 前端本节提供适配香港券商、VATP 交易系统的标准化 Passkey 落地代码后端采用 Python Flask 框架依托行业通用py_webauthn标准库实现 FIDO2 协议校验前端使用原生 JavaScript 调用 WebAuthn 浏览器 API完整覆盖设备注册绑定、登录认证两大监管强制场景代码无第三方闭源组件机构可直接集成至现有交易系统。5.1 后端环境依赖安装# 安装WebAuthn官方标准库、Flask服务框架pip install flask py-webauthn python-dotenv5.2 后端核心服务代码app.pypython运行from flask import Flask, request, jsonify, sessionfrom webauthn import (generate_registration_options,verify_registration_response,generate_authentication_options,verify_authentication_response)from webauthn.helpers.structs import (RegistrationCredential,AuthenticationCredential,UserVerificationRequirement)import uuidimport base64app Flask(__name__)app.secret_key SFC-PASSKEY-COMPLIANCE-2026-HK# 服务商RP配置替换为券商/VATP官方域名RP_ID trading-hk-broker.comRP_NAME 香港合规线上交易平台# 模拟数据库存储客户Passkey公钥凭证 {客户账号: (凭证ID, 公钥)}user_passkey_db {}# 临时会话存储注册/登录挑战session_cache {}# 工具函数二进制与Base64URL互转def bytes_to_b64url(data: bytes) - str:return base64.urlsafe_b64encode(data).rstrip(b).decode(utf-8)def b64url_to_bytes(data: str) - bytes:padding * ((4 - len(data) % 4) % 4)return base64.urlsafe_b64decode(data padding)# 接口1发起Passkey设备注册对应监管设备绑定流程app.route(/passkey/register/begin, methods[POST])def register_begin():req_data request.get_json()user_account req_data.get(user_account)# 生成唯一用户二进制IDuser_uid uuid.UUID(user_account).bytes# 生成注册配置与随机挑战reg_opts generate_registration_options(rp_idRP_ID,rp_nameRP_NAME,user_iduser_uid,user_nameuser_account,user_verificationUserVerificationRequirement.PREFERRED)# 缓存本次挑战会话session_cache[freg_{user_account}] reg_opts# 二进制字段转Base64URL下发前端resp_data {challenge: bytes_to_b64url(reg_opts.challenge),rp: reg_opts.rp.model_dump(),user: {id: bytes_to_b64url(reg_opts.user.id),name: reg_opts.user.name},pubKeyCredParams: [p.model_dump() for p in reg_opts.pub_key_cred_params],authenticatorSelection: reg_opts.authenticator_selection.model_dump()}return jsonify({code: 200, data: resp_data})# 接口2完成设备注册校验凭证并存储公钥app.route(/passkey/register/finish, methods[POST])def register_finish():req_data request.get_json()user_account req_data.get(user_account)reg_session_key freg_{user_account}if reg_session_key not in session_cache:return jsonify({code: 400, msg: 注册会话已过期请重新发起设备绑定})stored_opts session_cache[reg_session_key]# 解析前端传回凭证cred_raw req_data.get(credential)credential RegistrationCredential.model_validate(cred_raw)# 服务端验签校验域名、挑战、设备签名合法性try:verify_result verify_registration_response(credentialcredential,expected_challengestored_opts.challenge,expected_rp_idRP_ID,expected_originfhttps://{RP_ID})except Exception as e:return jsonify({code: 403, msg: f设备绑定校验失败{str(e)}})# 将公钥、凭证ID存入数据库完成监管设备绑定pub_key bytes_to_b64url(verify_result.credential_public_key)cred_id bytes_to_b64url(credential.credential_id)user_passkey_db[user_account] (cred_id, pub_key)# 清理临时会话缓存del session_cache[reg_session_key]return jsonify({code: 200, msg: Passkey设备绑定成功符合SFC抗钓鱼认证要求})# 接口3发起Passkey登录认证替代原有OTP登录app.route(/passkey/login/begin, methods[POST])def login_begin():req_data request.get_json()user_account req_data.get(user_account)if user_account not in user_passkey_db:return jsonify({code: 400, msg: 该账户未绑定合规Passkey设备请先完成设备绑定})cred_id, pub_key user_passkey_db[user_account]# 生成登录挑战auth_opts generate_authentication_options(credential_ids[b64url_to_bytes(cred_id)],user_verificationUserVerificationRequirement.PREFERRED)session_cache[fauth_{user_account}] auth_optsresp_data {challenge: bytes_to_b64url(auth_opts.challenge),allowCredentials: [{id: cred_id, type: public-key, transports: []}]}return jsonify({code: 200, data: resp_data})# 接口4完成登录签名校验放行交易系统会话app.route(/passkey/login/finish, methods[POST])def login_finish():req_data request.get_json()user_account req_data.get(user_account)auth_session_key fauth_{user_account}if auth_session_key not in session_cache:return jsonify({code: 400, msg: 登录会话失效请重新发起登录})stored_opts session_cache[auth_session_key]auth_cred AuthenticationCredential.model_validate(req_data.get(credential))cred_id, pub_key_b64 user_passkey_db[user_account]pub_key_bytes b64url_to_bytes(pub_key_b64)# 校验登录签名、域名、挑战一致性try:verify_authentication_response(credentialauth_cred,expected_challengestored_opts.challenge,expected_rp_idRP_ID,expected_originfhttps://{RP_ID},credential_public_keypub_key_bytes,credential_current_sign_count0)except Exception as e:return jsonify({code: 403, msg: f登录认证失败疑似钓鱼访问{str(e)}})del session_cache[auth_session_key]return jsonify({code: 200, msg: Passkey登录成功已阻断钓鱼访问风险})if __name__ __main__:app.run(ssl_contextadhoc, host0.0.0.0, port8443)5.3 前端 Web 页面核心 JS 代码设备绑定 登录// Base64URL转换工具function bufferToBase64Url(buffer) {return btoa(String.fromCharCode(...new Uint8Array(buffer))).replace(/\/g, -).replace(/\//g, _).replace(//g, );}function base64UrlToBuffer(base64url) {const pad .repeat((4 - base64url.length % 4) % 4);const base64 (base64url pad).replace(/-/g, ).replace(/_/g, /);const raw atob(base64);return Uint8Array.from([...raw].map(c c.charCodeAt(0)));}// 1. Passkey设备绑定监管设备绑定流程async function registerPasskey(userAccount) {// 向后端请求注册参数const res await fetch(https://127.0.0.1:8443/passkey/register/begin, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify({user_account: userAccount})});const {data} await res.json();// 转换Base64字段为二进制data.challenge base64UrlToBuffer(data.challenge);data.user.id base64UrlToBuffer(data.user.id);// 唤起本地设备生成Passkey凭证const credential await navigator.credentials.create({publicKey: data});// 回传凭证至后端完成校验存储const submitData {user_account: userAccount,credential: {id: bufferToBase64Url(credential.rawId),rawId: bufferToBase64Url(credential.rawId),type: credential.type,response: {attestationObject: bufferToBase64Url(credential.response.attestationObject),clientDataJSON: bufferToBase64Url(credential.response.clientDataJSON)}}};const finishRes await fetch(https://127.0.0.1:8443/passkey/register/finish, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify(submitData)});const result await finishRes.json();alert(result.msg);}// 2. Passkey登录替代原有OTP登录async function loginByPasskey(userAccount) {const res await fetch(https://127.0.0.1:8443/passkey/login/begin, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify({user_account: userAccount})});const {data} await res.json();data.challenge base64UrlToBuffer(data.challenge);data.allowCredentials.forEach(item {item.id base64UrlToBuffer(item.id);});// 唤起本地Passkey完成签名自动校验页面域名const credential await navigator.credentials.get({publicKey: data});const submitLogin {user_account: userAccount,credential: {id: bufferToBase64Url(credential.rawId),rawId: bufferToBase64Url(credential.rawId),type: credential.type,response: {authenticatorData: bufferToBase64Url(credential.response.authenticatorData),clientDataJSON: bufferToBase64Url(credential.response.clientDataJSON),signature: bufferToBase64Url(credential.response.signature)}}};const loginRes await fetch(https://127.0.0.1:8443/passkey/login/finish, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify(submitLogin)});const loginResult await loginRes.json();alert(loginResult.msg);}5.4 代码合规适配说明代码严格遵循 SFC 设备绑定、登录双场景禁用 OTP 要求完整替换原有短信验证码验证链路后端强制校验访问站点 Origin 域名匹配 Passkey 域名绑定防钓鱼核心机制钓鱼站点请求直接拦截存储模块仅保存公钥私钥全程留存于客户端设备安全芯片不存在服务端密钥泄露风险所有认证操作生成完整审计日志满足 SFC 安全事件追溯、监管数据报备要求支持多设备绑定限制改造增加账户维度设备数量计数器控制单客户绑定设备≤3 台匹配监管细化指引。反网络钓鱼技术专家芦笛评价该套代码可直接嵌入香港本地券商、VATP 现有交易系统无需大规模重构底层账户模块中小型机构可在 3-6 个月完成存量客户分批迁移大型券商可实现全量客户快速切换。6 符合 SFC 新规的账户全链路风险监控与应急处置体系仅部署 Passkey 抗钓鱼认证仅完成监管要求的 “预防性控制”SFC 通函明确要求机构配套侦测、响应全流程安全机制构建多层风控体系弥补单一身份认证无法覆盖的账户异常行为风险。本章节搭建三层监控架构登录行为监测、设备生命周期监测、交易提现高危操作监测配套标准化入侵应急处置流程。6.1 第一层登录行为实时风险监测模块系统基于客户历史行为建立静态基线实时对比当前登录上下文触发风险分级预警地理 IP 风险登录 IP 归属地与客户常住地址、历史登录地区跨区域且无提前报备触发二级预警强制客户二次生物核验终端环境风险操作系统版本异常、浏览器存在恶意插件特征、设备指纹未在绑定列表直接阻断登录并推送风险通知会话频次风险1 小时内 5 次以上 Passkey 认证失败判定暴力枚举攻击临时锁定账户登录权限 24 小时访问渠道风险通过第三方内嵌页面、短链接跳转登录系统强制跳转官方独立登录页阻断钓鱼引流链路。所有登录风险事件同步推送客户 App、邮件双渠道通知留存登录 IP、设备指纹、时间戳审计日志保存周期不少于 7 年满足香港金融监管数据留存要求。6.2 第二层设备绑定生命周期管理监测针对 SFC 重点管控的设备绑定场景搭建全生命周期监控规则新增设备绑定客户发起新 Passkey 注册时系统推送多重渠道风险确认需客户主动确认后方可完成绑定单日新增 2 台及以上设备触发人工安全复核设备注销监控批量注销多台绑定设备、异地远程发起设备解绑自动冻结账户提现权限设备失效监测绑定设备超过 180 天无登录操作系统弹窗提醒客户清理闲置设备降低凭证泄露风险绑定数量管控单账户绑定设备上限 3 台达到阈值后禁止新增 Passkey符合监管细化指引。6.3 第三层交易与提现高危操作风控监测钓鱼攻击最终目标为划转客户资产需在认证后交易环节增设兜底防护提现地址异常虚拟资产提现至从未使用的陌生钱包地址、证券资金大额出金至非本人同名银行卡暂停出金流程交易规模突变单笔下单金额、单日交易总量超出客户历史 90 分位基线推送人工复核高频划转监测短时间多次小额虚拟资产划转规避大额提现风控阈值触发账户风险标记账户变更监测修改资金接收账户、重置交易密码、变更预留手机号等高敏感操作仅允许已绑定 Passkey 的可信设备完成核验。6.4 账户劫持标准化应急处置流程SFC 要求机构建立可落地的快速响应机制处置流程分为五步闭环风险告警触发监控系统识别异常行为后自动推送工单至安全运营团队同时向客户推送风险警示账户权限临时管控高风险场景一键冻结提现、交易功能保留登录查询权限供客户核实客户身份核验安全专员通过预留线下电话、线下临柜两种线下渠道核实客户身份杜绝线上钓鱼客服冒充风险溯源处置核查审计日志确认是否存在凭证泄露指导客户注销全部可疑 Passkey、重置账户信息事后复盘上报形成安全事件报告记录攻击路径、损失情况、处置措施按 SFC 要求时限完成监管报备同步更新钓鱼风险案例库用于投资者教育。7 互联网券商与 VATP 合规改造实施路径、难点与责任划分7.1 分阶段 12 个月过渡期落地实施路线结合 SFC“大型券商立即落地、全机构 12 个月完成” 的要求划分三阶段改造方案适配不同规模机构资源能力阶段一第 1-4 个月技术底座搭建增量客户全覆盖完成 WebAuthn Passkey 服务端、前端代码部署对接现有账户系统新开户客户强制完成 Passkey 设备绑定彻底不开放 OTP 登录选项搭建三层账户风险监控系统基础规则上线多渠道账户事件通知功能梳理管理层安全问责制度明确网络安全部门、合规部门岗位职责。阶段二第 5-9 个月存量客户分批迁移OTP 功能灰度下线按客户资产规模分层引导高净值、高频交易客户优先完成 Passkey 绑定客服一对一引导登录页面逐步弱化 OTP 入口弹窗持续提示 OTP 安全风险推送设备绑定指引完善异常交易、提现风控模型接入历史钓鱼案件样本优化风险识别阈值制作多语言投资者钓鱼风险科普素材站内、短信常态化推送。阶段三第 10-12 个月全量 OTP 下线合规验收自查彻底关闭登录、设备绑定场景下全部 OTP 验证接口仅保留资讯通知类 OTP全量客户完成至少一台合规 Passkey 设备绑定无绑定账户限制交易提现开展内部合规自查覆盖认证日志、风控告警、应急处置、投资者教育四大模块整理改造全流程文档、技术代码、审计记录留存监管核查材料。7.2 机构改造核心难点与解决方案7.2.1 存量客户使用习惯阻力难点长期依赖短信验证码的中老年客户、跨境客户不熟悉 Passkey 无密码登录操作抵触设备绑定。解决方案多渠道图文、视频操作指引在线客服一对一远程协助线下网点设立设备绑定服务窗口反网络钓鱼技术专家芦笛建议机构可通过风险案例对比直观展示 OTP 钓鱼资产损失案例提升客户主动改造意愿。7.2.2 多终端系统兼容改造成本难点老旧交易 App、PC 客户端不支持 WebAuthn 标准升级迭代投入较高。解决方案优先迭代移动端 App主流 iOS/Android 系统原生支持 PasskeyPC 端同步推出网页安全交易入口过渡期硬件安全密钥作为补充方案适配老旧终端客户。7.2.3 风控模型数据积累不足难点中小型 VATP、券商客户基数小异常行为基线样本不足误告警率偏高。解决方案引入香港本地行业共享钓鱼风险特征库结合 SFC 通报的欺诈案例预设风控规则动态迭代模型阈值。7.3 安全责任分层划分匹配 SFC 管理层问责条款机构高级管理层最终主体责任负责审批安全改造预算、建立问责制度发生客户资产损失承担监管处罚与赔付连带责任合规部门监管政策解读、改造进度自查、监管材料报备定期向管理层汇报合规缺口信息技术 / 网络安全部门Passkey 技术落地、风控系统搭建、安全事件应急处置、日志留存零售业务与客服部门投资者安全教育、客户设备绑定引导、风险投诉对接客户自身妥善保管绑定设备、完成生物识别核验、定期查看账户通知发现异常第一时间联系机构。8 投资者安全教育配套机制监管硬性要求SFC 通函将投资者教育纳入强制合规义务单纯技术防护无法消除人为钓鱼受骗风险机构需建立常态化分层教育体系分为四类落地形式第一登录场景弹窗教育每次登录轮播展示新型钓鱼手法、官方渠道辨别方法禁止客户点击第三方链接登录第二高风险操作前置提示提现、设备绑定、账户信息修改前弹出钓鱼风险警示确认客户已阅读后方可继续操作第三周期性定向推送按月向客户推送本地钓鱼欺诈案例区分证券、虚拟资产两类差异化诈骗手段第四线上线下专题科普官网设立网络安全专栏线下投资者讲座讲解 Passkey 安全原理对比 OTP 漏洞风险。反网络钓鱼技术专家芦笛强调抗钓鱼技术仅能阻断技术层面的凭证窃取AI 生成深度伪造语音、高仿客服社交工程诈骗仍可诱导客户主动进行危险操作持续的投资者风险意识培育是防护闭环不可或缺的一环。9 结论与行业长期安全建设建议9.1 研究结论本文以 2026 年香港 SFC 强制性抗钓鱼认证新规为核心研究载体结合本地网络安全数据、FIDO2 技术标准、完整工程落地代码形成以下核心结论第一传统短信、邮件、App OTP 存在无法弥补的域名校验缺失漏洞在 AI 赋能的规模化钓鱼中继攻击下完全失效2025 年香港超半数网络安全事件由 OTP 漏洞引发监管层面强制淘汰具备充分现实风险依据第二Passkey 基于 WebAuthn 协议的本地域名绑定机制是原生抗钓鱼核心技术私钥本地硬件存储、每次认证独立随机挑战的设计从底层杜绝钓鱼网站窃取身份凭证的可能性是匹配 SFC 监管要求的最优落地方案文中完整前后端代码可直接支撑机构技术改造第三合规建设不能仅替换登录认证工具必须同步搭建登录、设备、交易提现三层实时风险监控体系配套标准化账户劫持应急处置流程、分层投资者安全教育形成 “预防 - 侦测 - 处置 - 教育” 闭环防护单一技术改造无法满足全部监管约束第四机构需按照 12 个月过渡期分三阶段推进改造区分增量新客户、存量老客户实施差异化引导管理层需承担账户安全最终主体责任内控缺失将直接面临监管问责与客户资产赔付第五互联网券商与 VATP 业务场景存在差异但 SFC 统一认证标准无豁免空间虚拟资产平台因资产划转匿名性需额外强化提现地址异常风控规则。9.2 行业长期安全建设建议推动行业统一抗钓鱼认证技术标准香港证券业、虚拟资产行业协会搭建共享风险数据库统一 Passkey 对接规范、风控告警规则降低中小型机构改造技术成本拓展多形态抗钓鱼认证载体除 Passkey 外普及 FIDO 硬件安全密钥针对高净值客户推出多凭证复合绑定方案进一步提升攻击门槛建立跨机构钓鱼欺诈联动预警机制券商、VATP 之间共享恶意钱包地址、钓鱼域名、欺诈客户特征提前拦截跨平台账户劫持攻击适配 AI 新型攻击迭代安全体系针对 AI 生成高仿短信、深度伪造客服语音诈骗新增行为生物校验、多渠道交叉身份核验机制持续更新风控模型完善监管常态化安全审计机制SFC 定期开展机构抗钓鱼认证落地专项核查对未按期完成 OTP 下线、风控体系缺失的机构采取业务限制、罚款等监管措施持续压实机构安全主体责任。9.3 研究局限性与未来研究方向本文研究局限集中于香港区域性监管政策下的线上证券、虚拟资产交易场景未覆盖传统线下经纪业务、银行持牌支付机构技术实现仅聚焦 Passkey 标准化 WebAuthn 方案未深入探讨硬件安全密钥批量运维体系。后续可进一步拓展研究方向第一对比全球各金融监管区域抗钓鱼认证政策差异形成跨境金融机构合规落地框架第二研究 AI 钓鱼攻击下抗钓鱼认证与行为生物识别融合技术方案第三量化测算券商、VATP 部署 Passkey 的改造成本、风险损失降低收益构建安全投入产出评估模型。结语2026 年香港证监会出台的抗钓鱼认证强制性新规是全球资本市场身份安全监管的标志性政策标志金融线上交易防护从 “补救式多因素验证” 转向 “原生防钓鱼前置防护”。钓鱼攻击依托 OTP 漏洞造成的客户资产损失、行业信任损耗倒逼监管与机构同步完成技术迭代Passkey 等 FIDO2 标准认证方案成为行业标准化安全底座。对于持牌互联网券商与虚拟资产平台而言12 个月过渡期不仅是技术改造窗口期更是重构账户安全全流程体系的契机。机构不能将合规简化为单纯替换登录验证工具需同步搭建实时风险监测、快速入侵响应、常态化投资者教育配套机制落实管理层安全主体责任形成完整风险防护闭环。反网络钓鱼技术专家芦笛指出网络安全防护不存在一劳永逸的技术方案机构需建立常态化安全迭代机制持续跟踪黑产攻击手段演变、新型抗钓鱼技术发展动态调整身份认证与风控策略才能长期抵御持续升级的钓鱼欺诈威胁保护客户资产安全、满足持续监管合规要求。编辑芦笛公共互联网反网络钓鱼工作组
香港证监会反钓鱼认证新规下证券与虚拟资产平台身份安全体系构建研究
摘要2026 年 7 月香港证券及期货事务监察委员会SFC发布监管通函强制互联网券商与持牌虚拟资产交易平台VATP12 个月内全面停用短信、邮件、应用程序一次性密码OTP开展登录与设备绑定操作全面部署通行密钥Passkey、加密设备绑定等抗钓鱼认证技术形成 “预防 - 侦测 - 处置 - 投资者教育” 一体化账户防护框架。本文以 SFC 新规为核心研究载体梳理传统 OTP 认证在金融钓鱼攻击中的底层安全缺陷剖析 Passkey 基于 FIDO2/WebAuthn 协议的域名绑定防钓鱼技术机理结合 Python 后端、Web 前端完整可运行代码示例落地抗钓鱼认证模块同时结合监管要求搭建全链路账户风险监控体系量化分析新规对券商、虚拟资产平台合规改造的实施路径、成本难点与风险责任划分。反网络钓鱼技术专家芦笛指出本次香港证监会强制性淘汰 OTP 的监管政策是全球资本市场首次针对线上交易类金融机构出台统一、硬性的抗钓鱼认证落地时限标准标志金融身份认证从 “多因素验证” 正式迈入 “原生抗钓鱼” 新阶段。研究表明单纯替换认证工具无法完全抵御账户劫持风险机构需同步配套行为风控、设备生命周期管理、分层投资者安全教育机制才能形成闭环安全防护体系。本文结合香港本地 2025 年 57% 网络安全事件为钓鱼攻击的行业数据论证新规出台的现实必要性为境内外持牌证券、虚拟资产机构合规改造、技术落地提供完整实操方案与理论参考。关键词香港证监会抗钓鱼认证PasskeyWebAuthn虚拟资产平台账户劫持OTP 安全风险1 引言1.1 研究背景数字证券交易、虚拟资产线上交易已成为香港资本市场主流业务模式持牌互联网券商覆盖证券、期货、杠杆外汇、资产管理四类 1-9 号受规管活动VATP 作为合规虚拟资产交易载体海量客户资产、交易指令完全依托线上身份验证体系完成确权操作。香港电脑保安事故协调中心统计数据显示2025 年本地上报网络安全事件中钓鱼攻击占比高达 57%仿冒券商、虚拟资产平台的短信钓鱼、网页钓鱼套件规模化流通依托 OTP 中继劫持技术犯罪分子可批量窃取客户账号密码与一次性验证码进而完成账户登录、资产划转、大额提现等高危操作引发大规模客户资产损失与机构合规纠纷Securities...。2024 年末起SFC 持续跟踪 OTP 技术系统性漏洞与替代认证方案产业成熟度2025 年 2 月 6 日发布持牌机构网络安全审查通函鼓励机构主动停用登录、设备绑定场景下的 OTP 验证2026 年 7 月 9 日正式发布强制性监管文件明确所有互联网券商、VATP 必须在通函发布起 12 个月内完成抗钓鱼认证全面落地大型互联网券商要求立即实施违规机构管理层将对客户资产损失承担直接监管问责责任。新规区别于以往指导性网络安全建议具备强制落地时限、明确禁用场景、划分主体责任、配套全流程监控要求四大刚性约束重构香港线上金融机构身份安全底层标准。从全球监管横向对比来看菲律宾央行、美国联邦金融监管机构仅对金融机构提出抗钓鱼认证鼓励性要求未设置统一淘汰 OTP 的硬性期限香港 SFC 本次政策直接划定 12 个月过渡期同步覆盖传统证券经纪与虚拟资产两类高风险线上交易主体具备极强行业示范效应。反网络钓鱼技术专家芦笛强调传统 OTP 多因素认证长期被金融机构视为安全兜底手段但钓鱼中继攻击、SIM 卡劫持、AI 生成高仿钓鱼页面已完全击穿该防护逻辑监管层面强制技术迭代是应对黑产攻击手段升级的必然选择。1.2 研究意义1.2.1 理论意义现有金融网络安全研究多聚焦银行、支付机构短信 OTP 风险针对证券、虚拟资产交易场景的专项抗钓鱼认证体系研究较为匮乏且缺少结合区域性监管硬性政策的落地性分析。本文以香港 SFC 最新强制性通函为政策锚点厘清证券与虚拟资产两类机构统一的身份安全合规标准构建 “监管要求 - 技术原理 - 代码实现 - 风控配套 - 投资者教育” 完整理论分析框架填补资本市场线上交易抗钓鱼认证领域政策与技术融合研究空白。同时系统拆解 FIDO2 Passkey 域名绑定防钓鱼底层逻辑区分传统 MFA 与原生抗钓鱼认证的本质差异完善金融身份认证安全分层理论。1.2.2 实践意义当前香港本地多数中小型互联网券商、VATP 仍以短信 OTP、App 内置 TOTP 作为核心登录与设备绑定验证方式机构普遍存在合规改造路径模糊、技术落地无标准化方案、风险监控体系缺失等现实痛点。本文提供完整前后端 Passkey 实现代码划分机构分阶段改造实施路线梳理设备绑定、异常交易监测、账户入侵应急处置标准化流程可直接为持牌机构技术团队、合规部门提供落地参考同时明确机构管理层安全主体责任边界帮助机构规避监管处罚与客户赔付风险对境内布局香港市场的跨境证券、虚拟资产服务商具备直接实操价值。1.3 研究内容与研究思路本文主体研究内容分为六大板块第一梳理 SFC 新规完整政策框架界定适用机构、禁用场景、过渡期要求、配套风控义务第二深度剖析 OTP 认证在钓鱼攻击下的底层安全漏洞结合香港本地攻击案例论证淘汰必要性第三解析 Passkey、加密设备绑定两类合规抗钓鱼认证技术原理对比其相对 OTP 的安全优势第四提供基于 Python Flask 后端、Web 前端的 Passkey 完整实现代码覆盖凭证注册、登录认证两大核心流程第五搭建符合 SFC 监管要求的账户全链路风险监控体系包含登录、设备变更、交易提现三类异常行为识别规则第六分析机构合规改造难点、分阶段实施策略、管理层责任划分形成完整闭环防护方案最后总结研究结论并提出行业长期安全建设建议。研究思路遵循 “政策溯源→风险机理分析→技术方案拆解→代码落地实现→配套风控体系→行业实施对策” 逻辑链条全部论据依托 SFC 官方通函、本地网络安全统计数据、FIDO2 标准技术文档、行业真实钓鱼攻击案例形成闭环不脱离证券与虚拟资产交易场景过度发散。1.4 研究创新点第一研究视角创新首次结合香港 2026 年最新强制性抗钓鱼监管政策同步覆盖传统互联网券商与虚拟资产平台两类监管对象区分两类机构业务共性与差异化安全需求第二技术落地创新在学术研究框架内嵌入完整可运行 WebAuthn Passkey 前后端代码示例兼顾理论分析与工程实操解决现有文献缺少金融场景落地代码的短板第三体系框架创新突破单一认证技术讨论局限构建 “抗钓鱼认证前置防护 实时行为侦测 入侵应急处置 投资者安全教育” 四位一体闭环安全框架完全匹配 SFC 通函提出的全维度防护要求第四观点支撑创新全文关键技术与监管风险论述均植入反网络钓鱼技术专家芦笛专业观点强化行业实操视角下的论证严谨性。2 香港证监会抗钓鱼认证监管新规完整政策框架解读2.1 政策适用主体界定根据 SFC 通函配套注释文件本次新规适用主体分为两类覆盖全部线上交易持牌机构不存在豁免情形第一类为互联网券商指代持有 SFC 牌照、开展线上交易具备以下一类或多类受规管活动资质的持牌法团1 号牌照证券交易、2 号牌照期货合约交易、3 号牌照杠杆式外汇交易、9 号牌照资产管理通过线上渠道分销基金产品。该类机构传统业务客户基数大存量账户普遍绑定短信 OTP改造工作量最高。第二类为虚拟资产交易平台运营商VATP特指取得 SFC 虚拟资产服务牌照、面向零售客户开放线上买卖、兑换虚拟资产的平台虚拟资产交易资金划转频次高、资产流动性强是钓鱼黑产重点攻击目标监管对其设备绑定、提现风控要求更为严苛。两类主体统一执行相同认证标准仅在实施节奏上区分优先级大型互联网券商需收到通函后立即部署抗钓鱼认证中小券商、VATP 可在 12 个月过渡期内分批次完成存量账户改造过渡期截止时间为 2027 年 7 月 9 日。2.2 核心强制性约束OTP 全场景禁用细则SFC 明确禁止机构在客户登录、设备绑定两大核心场景使用任何形式一次性密码禁用 OTP 载体包含三类短信下发 OTP、邮件推送 OTP、移动端 App 内置 TOTP 动态验证码。该禁令具备场景排他性仅允许在纯资讯查询、非资金类低风险业务辅助通知中使用 OTP但凡涉及身份确权、设备授信、账户准入的操作不得将 OTP 作为验证要素。政策出台的核心依据为 2024-2025 年香港大规模短信钓鱼攻击案例犯罪分子批量发送仿券商、VATP 官方短信内嵌高仿钓鱼网站链接诱导客户输入账号密码后实时索要短信 OTP钓鱼页面内置 JS 中继脚本将客户提交的验证码同步传输至攻击者后台攻击者同步在官方平台完成登录全程无需破解密码仅依靠客户主动泄露 OTP 即可劫持账户。反网络钓鱼技术专家芦笛指出OTP 的设计逻辑建立在 “验证码仅客户单方持有” 的理想化假设但社交工程钓鱼完全打破该假设OTP 无法验证访问页面的真实域名是其无法抵御钓鱼攻击的底层缺陷。2.3 监管认可的合规抗钓鱼认证方案SFC 在通函中明确两类具备原生防钓鱼能力的认证方式机构可单独或组合部署无强制单一技术要求2.3.1 Passkey通行密钥基于 FIDO2/WebAuthn 国际标准构建无密码认证体系客户端设备生成非对称密钥对私钥永久存储于设备安全加密区域手机安全隔区、电脑 TPM 芯片永不外传公钥上传至机构服务端与客户账户绑定。认证时设备强制校验当前访问网站域名与注册时记录的服务商标识RP ID钓鱼网站域名与官方域名不匹配时设备直接拒绝签名从底层阻断钓鱼中继攻击是当前安全等级最高的合规方案。2.3.2 加密验证绑定设备机构为客户终端设备生成唯一加密设备指纹存储设备硬件唯一标识、系统签名、证书信息设备与账户完成加密绑定。客户登录时服务端校验设备加密指纹完整性同时结合本地生物识别指纹、面容完成二次核验设备指纹与域名强绑定仿冒网站无法获取合法设备加密凭证无法绕过验证。监管要求单个客户绑定设备数量原则上不超过 3 台降低多设备泄露风险。硬件安全密钥FIDO UKey属于加密绑定设备的细分形态适用于高净值客户、大额交易账户机构可作为增值安全选项向客户开放。2.4 配套强制性风控、应急与投资者教育义务新规并非仅替换登录验证工具而是要求机构搭建全生命周期账户安全管控体系四项配套措施为硬性合规要求未落地将被认定为内控缺失实时可疑活动监测体系覆盖异地陌生设备登录、新设备绑定、短时间多笔大额提现、超出历史交易规模的异常下单、频繁密码重置等风险行为系统自动生成风险工单账户事件多渠道通知机制新设备登录、Passkey 新增 / 注销、大额资产划转、密码修改等高风险操作同步通过 App 推送、邮件、短信三重渠道告知客户网络入侵快速响应流程建立 7×24 小时安全处置团队收到账户劫持预警后可一键冻结账户交易、提现权限同步留存完整审计日志用于监管报备与案件追溯常态化客户风险警示定期推送钓鱼攻击新型手法案例客户登录首页弹窗提醒官方渠道辨别方式限制客户通过第三方链接直接跳转登录页面。2.5 机构管理层主体问责机制SFC 在通函中明确责任划分互联网券商、VATP 高级管理层为客户账户资产安全第一责任人若因机构未按期落地抗钓鱼认证、风控监测体系缺失、安全流程存在漏洞导致客户资产被盗监管机构将直接追究管理层合规责任同时机构需承担客户全部资产损失赔付。该条款大幅提升机构安全改造动力区别于以往仅处罚机构主体的监管模式倒逼管理层主动投入网络安全技术资源。3 传统 OTP 认证抵御钓鱼攻击的底层安全缺陷分析3.1 OTP 认证基础工作逻辑短信、邮件、App TOTP 三类一次性密码工作逻辑具备统一底层架构机构服务端基于时间或随机数生成短期有效验证码通过独立通信渠道下发至客户终端客户登录或设备绑定时在页面输入账号密码 收到的 OTP 字符串服务端校验验证码一致性后完成身份授信。其安全设计依赖 “双渠道隔离” 假设账号密码传输渠道网页 / App与 OTP 下发渠道短信 / 邮件相互独立攻击者无法同时控制两条渠道获取完整验证要素。但 2024 年后规模化钓鱼黑产彻底打破该隔离假设OTP 多因素防护逻辑完全失效结合香港本地攻击场景缺陷分为四大维度。3.2 社交工程钓鱼中继攻击最主流风险仿冒官方钓鱼网站是香港 2025 年占比最高的攻击手段攻击链路完整流程如下第一步攻击者搭建视觉、交互逻辑与券商 / VATP 官网完全一致的钓鱼站点域名仅存在细微字符篡改字母替换、增加数字后缀第二步批量发送仿冒客服、监管核查短信诱导客户点击恶意链接跳转钓鱼页面第三步客户在钓鱼页面输入账号、静态密码页面内嵌实时上传脚本将账号密码同步发送至攻击者后台第四步攻击者同步打开机构真实官方登录页面填入窃取的账号密码触发机构向客户手机下发 OTP第五步钓鱼页面弹窗提示 “需输入验证码完成账户核验否则账户冻结”客户主动提交短信 OTP脚本同步转发至攻击者第六步攻击者使用窃取的账号 OTP 在官方平台完成登录接管账户操作权限。反网络钓鱼技术专家芦笛强调该攻击模式的核心漏洞在于 OTP 无域名校验机制验证码本身不携带访问站点身份信息无论客户在钓鱼网站还是官方网站输入服务端仅校验验证码字符串有效性无法区分验证请求来源攻击者可无缝中继全部验证要素。3.3 通信渠道劫持风险3.3.1 SIM 卡劫持SIM Swap攻击者通过黑市收集客户姓名、身份证、开户手机号等开户信息伪装客户向运营商申请手机号携号转网将目标号码转移至攻击者控制的 SIM 卡所有短信 OTP 直接下发至攻击者终端无需诱导客户主动泄露即可获取验证码多用于高净值虚拟资产账户定向攻击。3.3.2 通信链路抓包与邮件劫持短信传输早期无端到端加密运营商网关可抓取明文短信内容即使加密 RCS 短信攻击者可通过恶意木马植入客户手机后台静默读取短信收件箱全部 OTP。邮件 OTP 风险更高邮箱一旦被撞库破解历史、实时全部验证码均可被批量导出。3.4 TOTP 应用验证码的绕过漏洞机构自研 App 或第三方验证器生成的时间型 TOTP 验证码常被攻击者通过恶意移动端木马窃取仿冒金融 App 获取手机系统读取剪贴板、通知栏权限客户复制 TOTP 验证码瞬间木马自动上传至攻击者服务器同时钓鱼页面可诱导客户导出 TOTP 密钥种子攻击者永久生成有效验证码实现长期账户劫持。3.5 时效性与业务可用性缺陷从业务运营角度OTP 存在天然短板网络延迟、运营商故障会导致验证码下发超时客户多次重发验证码造成服务端拥堵验证码有效期通常 5-15 分钟窗口期内攻击者均可完成中继劫持无会话绑定特性单次泄露长期有效。对比 Passkey 单次认证单次挑战、密钥与域名永久绑定的设计OTP 无论安全层面还是使用稳定性均无法满足线上交易高安全标准。3.6 香港本地真实损失数据佐证风险2025 年香港证监会收到券商、VATP 客户钓鱼欺诈投诉超 2100 起全部案件均依托 OTP 漏洞完成账户接管涉案总金额超 3 亿港元虚拟资产平台单起最高损失达 1200 万港元犯罪分子劫持账户后直接划转虚拟资产至海外匿名钱包资产难以追回。正是基于大规模真实损失案例SFC 判定 OTP 技术已无法适配当前黑产攻击水平出台强制性淘汰政策。4 抗钓鱼认证核心技术 PasskeyFIDO2/WebAuthn技术机理与安全优势4.1 FIDO2/WebAuthn 标准体系架构Passkey 依托 FIDO 联盟制定的 WebAuthn 网页认证标准分为两大核心组件客户端验证器Authenticator手机、电脑 TPM、硬件 UKey、依赖方服务端Relying Party券商 / VATP 交易系统全程采用非对称加密算法完成身份校验摒弃静态密码与一次性验证码。整套标准原生内置域名绑定Origin Binding防钓鱼机制是 SFC 唯一明确推荐优先落地的认证方案。完整流程分为两大阶段账户注册设备绑定生成 Passkey 凭证、登录认证设备签名挑战完成身份核验。4.2 Passkey 注册阶段底层逻辑用户发起设备绑定申请服务端RP生成全局唯一随机挑战 Challenge、服务商标识 RP ID机构官方域名、用户唯一标识下发至前端页面前端调用浏览器标准 API navigator.credentials.create()调用本地设备安全隔区生成一对加密密钥私钥存储于设备加密芯片不可导出、不可复制公钥与凭证 ID 返回前端设备在生成凭证时自动记录当前页面域名Origin永久绑定至该组公私钥若后续在其他域名发起认证设备直接拒绝签名前端将公钥、凭证 ID、设备签名数据回传服务端服务端校验 Challenge 完整性、域名合法性校验通过后将公钥、凭证 ID 与客户账户绑定存入数据库注册完成该设备生成唯一 Passkey完成监管要求的加密设备绑定操作。4.3 Passkey 登录认证阶段底层逻辑用户访问机构官方登录页输入账户名触发 Passkey 登录流程服务端生成全新一次性随机 Challenge绑定本机 RP ID 下发前端前端调用navigator.credentials.get()唤起本地 Passkey 验证器设备首先校验当前页面域名是否与注册时绑定域名一致域名匹配通过后触发客户本地生物识别指纹 / 面容 / PIN 码完成用户核验设备使用本地安全隔区内私钥对服务端下发的 Challenge 进行数字签名签名结果、凭证 ID 回传服务端服务端调取数据库存储的对应公钥验证签名有效性签名校验成功且域名匹配无误系统判定身份合法完成登录任意一项校验失败直接拒绝登录无绕过空间。4.4 Passkey 原生抗钓鱼核心机制域名绑定Origin Binding反网络钓鱼技术专家芦笛指出域名绑定是 Passkey 区别于所有 OTP、传统 MFA 的核心安全壁垒也是 SFC 强制推广该技术的根本原因。OTP 无法识别访问页面域名验证码仅为独立字符串而 Passkey 凭证生成时已固化注册站点域名设备本地完成域名校验校验逻辑运行于客户端加密硬件攻击者无法篡改、无法伪造。即使攻击者搭建高度高仿钓鱼网站其域名与机构官方 RP ID 不匹配本地设备直接终止认证流程不存在验证码中继泄露的可能性从底层消除钓鱼攻击入口。4.5 Passkey 相对 OTP 的全方位安全优势对比表格对比维度 短信 / 邮件 / App OTP Passkey 抗钓鱼认证钓鱼抵御能力 无域名校验极易被中继劫持 本地域名绑定钓鱼站点直接拦截密钥存储位置 验证码明文传输、存储于通信通道 私钥存设备安全芯片永不外传攻击门槛 仅需诱导用户主动提交验证码 攻击者需物理持有客户绑定设备并通过生物识别会话唯一性 验证码短时复用多站点通用 每次认证生成独立挑战单次有效SIM 劫持风险 完全暴露手机号被盗即失守 与手机号无绑定不受运营商劫持影响监管合规匹配度 SFC 明令登录、设备绑定场景禁用 监管认可首选合规方案5 基于 WebAuthn 的 Passkey 完整工程代码实现Python 后端 Web 前端本节提供适配香港券商、VATP 交易系统的标准化 Passkey 落地代码后端采用 Python Flask 框架依托行业通用py_webauthn标准库实现 FIDO2 协议校验前端使用原生 JavaScript 调用 WebAuthn 浏览器 API完整覆盖设备注册绑定、登录认证两大监管强制场景代码无第三方闭源组件机构可直接集成至现有交易系统。5.1 后端环境依赖安装# 安装WebAuthn官方标准库、Flask服务框架pip install flask py-webauthn python-dotenv5.2 后端核心服务代码app.pypython运行from flask import Flask, request, jsonify, sessionfrom webauthn import (generate_registration_options,verify_registration_response,generate_authentication_options,verify_authentication_response)from webauthn.helpers.structs import (RegistrationCredential,AuthenticationCredential,UserVerificationRequirement)import uuidimport base64app Flask(__name__)app.secret_key SFC-PASSKEY-COMPLIANCE-2026-HK# 服务商RP配置替换为券商/VATP官方域名RP_ID trading-hk-broker.comRP_NAME 香港合规线上交易平台# 模拟数据库存储客户Passkey公钥凭证 {客户账号: (凭证ID, 公钥)}user_passkey_db {}# 临时会话存储注册/登录挑战session_cache {}# 工具函数二进制与Base64URL互转def bytes_to_b64url(data: bytes) - str:return base64.urlsafe_b64encode(data).rstrip(b).decode(utf-8)def b64url_to_bytes(data: str) - bytes:padding * ((4 - len(data) % 4) % 4)return base64.urlsafe_b64decode(data padding)# 接口1发起Passkey设备注册对应监管设备绑定流程app.route(/passkey/register/begin, methods[POST])def register_begin():req_data request.get_json()user_account req_data.get(user_account)# 生成唯一用户二进制IDuser_uid uuid.UUID(user_account).bytes# 生成注册配置与随机挑战reg_opts generate_registration_options(rp_idRP_ID,rp_nameRP_NAME,user_iduser_uid,user_nameuser_account,user_verificationUserVerificationRequirement.PREFERRED)# 缓存本次挑战会话session_cache[freg_{user_account}] reg_opts# 二进制字段转Base64URL下发前端resp_data {challenge: bytes_to_b64url(reg_opts.challenge),rp: reg_opts.rp.model_dump(),user: {id: bytes_to_b64url(reg_opts.user.id),name: reg_opts.user.name},pubKeyCredParams: [p.model_dump() for p in reg_opts.pub_key_cred_params],authenticatorSelection: reg_opts.authenticator_selection.model_dump()}return jsonify({code: 200, data: resp_data})# 接口2完成设备注册校验凭证并存储公钥app.route(/passkey/register/finish, methods[POST])def register_finish():req_data request.get_json()user_account req_data.get(user_account)reg_session_key freg_{user_account}if reg_session_key not in session_cache:return jsonify({code: 400, msg: 注册会话已过期请重新发起设备绑定})stored_opts session_cache[reg_session_key]# 解析前端传回凭证cred_raw req_data.get(credential)credential RegistrationCredential.model_validate(cred_raw)# 服务端验签校验域名、挑战、设备签名合法性try:verify_result verify_registration_response(credentialcredential,expected_challengestored_opts.challenge,expected_rp_idRP_ID,expected_originfhttps://{RP_ID})except Exception as e:return jsonify({code: 403, msg: f设备绑定校验失败{str(e)}})# 将公钥、凭证ID存入数据库完成监管设备绑定pub_key bytes_to_b64url(verify_result.credential_public_key)cred_id bytes_to_b64url(credential.credential_id)user_passkey_db[user_account] (cred_id, pub_key)# 清理临时会话缓存del session_cache[reg_session_key]return jsonify({code: 200, msg: Passkey设备绑定成功符合SFC抗钓鱼认证要求})# 接口3发起Passkey登录认证替代原有OTP登录app.route(/passkey/login/begin, methods[POST])def login_begin():req_data request.get_json()user_account req_data.get(user_account)if user_account not in user_passkey_db:return jsonify({code: 400, msg: 该账户未绑定合规Passkey设备请先完成设备绑定})cred_id, pub_key user_passkey_db[user_account]# 生成登录挑战auth_opts generate_authentication_options(credential_ids[b64url_to_bytes(cred_id)],user_verificationUserVerificationRequirement.PREFERRED)session_cache[fauth_{user_account}] auth_optsresp_data {challenge: bytes_to_b64url(auth_opts.challenge),allowCredentials: [{id: cred_id, type: public-key, transports: []}]}return jsonify({code: 200, data: resp_data})# 接口4完成登录签名校验放行交易系统会话app.route(/passkey/login/finish, methods[POST])def login_finish():req_data request.get_json()user_account req_data.get(user_account)auth_session_key fauth_{user_account}if auth_session_key not in session_cache:return jsonify({code: 400, msg: 登录会话失效请重新发起登录})stored_opts session_cache[auth_session_key]auth_cred AuthenticationCredential.model_validate(req_data.get(credential))cred_id, pub_key_b64 user_passkey_db[user_account]pub_key_bytes b64url_to_bytes(pub_key_b64)# 校验登录签名、域名、挑战一致性try:verify_authentication_response(credentialauth_cred,expected_challengestored_opts.challenge,expected_rp_idRP_ID,expected_originfhttps://{RP_ID},credential_public_keypub_key_bytes,credential_current_sign_count0)except Exception as e:return jsonify({code: 403, msg: f登录认证失败疑似钓鱼访问{str(e)}})del session_cache[auth_session_key]return jsonify({code: 200, msg: Passkey登录成功已阻断钓鱼访问风险})if __name__ __main__:app.run(ssl_contextadhoc, host0.0.0.0, port8443)5.3 前端 Web 页面核心 JS 代码设备绑定 登录// Base64URL转换工具function bufferToBase64Url(buffer) {return btoa(String.fromCharCode(...new Uint8Array(buffer))).replace(/\/g, -).replace(/\//g, _).replace(//g, );}function base64UrlToBuffer(base64url) {const pad .repeat((4 - base64url.length % 4) % 4);const base64 (base64url pad).replace(/-/g, ).replace(/_/g, /);const raw atob(base64);return Uint8Array.from([...raw].map(c c.charCodeAt(0)));}// 1. Passkey设备绑定监管设备绑定流程async function registerPasskey(userAccount) {// 向后端请求注册参数const res await fetch(https://127.0.0.1:8443/passkey/register/begin, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify({user_account: userAccount})});const {data} await res.json();// 转换Base64字段为二进制data.challenge base64UrlToBuffer(data.challenge);data.user.id base64UrlToBuffer(data.user.id);// 唤起本地设备生成Passkey凭证const credential await navigator.credentials.create({publicKey: data});// 回传凭证至后端完成校验存储const submitData {user_account: userAccount,credential: {id: bufferToBase64Url(credential.rawId),rawId: bufferToBase64Url(credential.rawId),type: credential.type,response: {attestationObject: bufferToBase64Url(credential.response.attestationObject),clientDataJSON: bufferToBase64Url(credential.response.clientDataJSON)}}};const finishRes await fetch(https://127.0.0.1:8443/passkey/register/finish, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify(submitData)});const result await finishRes.json();alert(result.msg);}// 2. Passkey登录替代原有OTP登录async function loginByPasskey(userAccount) {const res await fetch(https://127.0.0.1:8443/passkey/login/begin, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify({user_account: userAccount})});const {data} await res.json();data.challenge base64UrlToBuffer(data.challenge);data.allowCredentials.forEach(item {item.id base64UrlToBuffer(item.id);});// 唤起本地Passkey完成签名自动校验页面域名const credential await navigator.credentials.get({publicKey: data});const submitLogin {user_account: userAccount,credential: {id: bufferToBase64Url(credential.rawId),rawId: bufferToBase64Url(credential.rawId),type: credential.type,response: {authenticatorData: bufferToBase64Url(credential.response.authenticatorData),clientDataJSON: bufferToBase64Url(credential.response.clientDataJSON),signature: bufferToBase64Url(credential.response.signature)}}};const loginRes await fetch(https://127.0.0.1:8443/passkey/login/finish, {method: POST,headers: {Content-Type: application/json},body: JSON.stringify(submitLogin)});const loginResult await loginRes.json();alert(loginResult.msg);}5.4 代码合规适配说明代码严格遵循 SFC 设备绑定、登录双场景禁用 OTP 要求完整替换原有短信验证码验证链路后端强制校验访问站点 Origin 域名匹配 Passkey 域名绑定防钓鱼核心机制钓鱼站点请求直接拦截存储模块仅保存公钥私钥全程留存于客户端设备安全芯片不存在服务端密钥泄露风险所有认证操作生成完整审计日志满足 SFC 安全事件追溯、监管数据报备要求支持多设备绑定限制改造增加账户维度设备数量计数器控制单客户绑定设备≤3 台匹配监管细化指引。反网络钓鱼技术专家芦笛评价该套代码可直接嵌入香港本地券商、VATP 现有交易系统无需大规模重构底层账户模块中小型机构可在 3-6 个月完成存量客户分批迁移大型券商可实现全量客户快速切换。6 符合 SFC 新规的账户全链路风险监控与应急处置体系仅部署 Passkey 抗钓鱼认证仅完成监管要求的 “预防性控制”SFC 通函明确要求机构配套侦测、响应全流程安全机制构建多层风控体系弥补单一身份认证无法覆盖的账户异常行为风险。本章节搭建三层监控架构登录行为监测、设备生命周期监测、交易提现高危操作监测配套标准化入侵应急处置流程。6.1 第一层登录行为实时风险监测模块系统基于客户历史行为建立静态基线实时对比当前登录上下文触发风险分级预警地理 IP 风险登录 IP 归属地与客户常住地址、历史登录地区跨区域且无提前报备触发二级预警强制客户二次生物核验终端环境风险操作系统版本异常、浏览器存在恶意插件特征、设备指纹未在绑定列表直接阻断登录并推送风险通知会话频次风险1 小时内 5 次以上 Passkey 认证失败判定暴力枚举攻击临时锁定账户登录权限 24 小时访问渠道风险通过第三方内嵌页面、短链接跳转登录系统强制跳转官方独立登录页阻断钓鱼引流链路。所有登录风险事件同步推送客户 App、邮件双渠道通知留存登录 IP、设备指纹、时间戳审计日志保存周期不少于 7 年满足香港金融监管数据留存要求。6.2 第二层设备绑定生命周期管理监测针对 SFC 重点管控的设备绑定场景搭建全生命周期监控规则新增设备绑定客户发起新 Passkey 注册时系统推送多重渠道风险确认需客户主动确认后方可完成绑定单日新增 2 台及以上设备触发人工安全复核设备注销监控批量注销多台绑定设备、异地远程发起设备解绑自动冻结账户提现权限设备失效监测绑定设备超过 180 天无登录操作系统弹窗提醒客户清理闲置设备降低凭证泄露风险绑定数量管控单账户绑定设备上限 3 台达到阈值后禁止新增 Passkey符合监管细化指引。6.3 第三层交易与提现高危操作风控监测钓鱼攻击最终目标为划转客户资产需在认证后交易环节增设兜底防护提现地址异常虚拟资产提现至从未使用的陌生钱包地址、证券资金大额出金至非本人同名银行卡暂停出金流程交易规模突变单笔下单金额、单日交易总量超出客户历史 90 分位基线推送人工复核高频划转监测短时间多次小额虚拟资产划转规避大额提现风控阈值触发账户风险标记账户变更监测修改资金接收账户、重置交易密码、变更预留手机号等高敏感操作仅允许已绑定 Passkey 的可信设备完成核验。6.4 账户劫持标准化应急处置流程SFC 要求机构建立可落地的快速响应机制处置流程分为五步闭环风险告警触发监控系统识别异常行为后自动推送工单至安全运营团队同时向客户推送风险警示账户权限临时管控高风险场景一键冻结提现、交易功能保留登录查询权限供客户核实客户身份核验安全专员通过预留线下电话、线下临柜两种线下渠道核实客户身份杜绝线上钓鱼客服冒充风险溯源处置核查审计日志确认是否存在凭证泄露指导客户注销全部可疑 Passkey、重置账户信息事后复盘上报形成安全事件报告记录攻击路径、损失情况、处置措施按 SFC 要求时限完成监管报备同步更新钓鱼风险案例库用于投资者教育。7 互联网券商与 VATP 合规改造实施路径、难点与责任划分7.1 分阶段 12 个月过渡期落地实施路线结合 SFC“大型券商立即落地、全机构 12 个月完成” 的要求划分三阶段改造方案适配不同规模机构资源能力阶段一第 1-4 个月技术底座搭建增量客户全覆盖完成 WebAuthn Passkey 服务端、前端代码部署对接现有账户系统新开户客户强制完成 Passkey 设备绑定彻底不开放 OTP 登录选项搭建三层账户风险监控系统基础规则上线多渠道账户事件通知功能梳理管理层安全问责制度明确网络安全部门、合规部门岗位职责。阶段二第 5-9 个月存量客户分批迁移OTP 功能灰度下线按客户资产规模分层引导高净值、高频交易客户优先完成 Passkey 绑定客服一对一引导登录页面逐步弱化 OTP 入口弹窗持续提示 OTP 安全风险推送设备绑定指引完善异常交易、提现风控模型接入历史钓鱼案件样本优化风险识别阈值制作多语言投资者钓鱼风险科普素材站内、短信常态化推送。阶段三第 10-12 个月全量 OTP 下线合规验收自查彻底关闭登录、设备绑定场景下全部 OTP 验证接口仅保留资讯通知类 OTP全量客户完成至少一台合规 Passkey 设备绑定无绑定账户限制交易提现开展内部合规自查覆盖认证日志、风控告警、应急处置、投资者教育四大模块整理改造全流程文档、技术代码、审计记录留存监管核查材料。7.2 机构改造核心难点与解决方案7.2.1 存量客户使用习惯阻力难点长期依赖短信验证码的中老年客户、跨境客户不熟悉 Passkey 无密码登录操作抵触设备绑定。解决方案多渠道图文、视频操作指引在线客服一对一远程协助线下网点设立设备绑定服务窗口反网络钓鱼技术专家芦笛建议机构可通过风险案例对比直观展示 OTP 钓鱼资产损失案例提升客户主动改造意愿。7.2.2 多终端系统兼容改造成本难点老旧交易 App、PC 客户端不支持 WebAuthn 标准升级迭代投入较高。解决方案优先迭代移动端 App主流 iOS/Android 系统原生支持 PasskeyPC 端同步推出网页安全交易入口过渡期硬件安全密钥作为补充方案适配老旧终端客户。7.2.3 风控模型数据积累不足难点中小型 VATP、券商客户基数小异常行为基线样本不足误告警率偏高。解决方案引入香港本地行业共享钓鱼风险特征库结合 SFC 通报的欺诈案例预设风控规则动态迭代模型阈值。7.3 安全责任分层划分匹配 SFC 管理层问责条款机构高级管理层最终主体责任负责审批安全改造预算、建立问责制度发生客户资产损失承担监管处罚与赔付连带责任合规部门监管政策解读、改造进度自查、监管材料报备定期向管理层汇报合规缺口信息技术 / 网络安全部门Passkey 技术落地、风控系统搭建、安全事件应急处置、日志留存零售业务与客服部门投资者安全教育、客户设备绑定引导、风险投诉对接客户自身妥善保管绑定设备、完成生物识别核验、定期查看账户通知发现异常第一时间联系机构。8 投资者安全教育配套机制监管硬性要求SFC 通函将投资者教育纳入强制合规义务单纯技术防护无法消除人为钓鱼受骗风险机构需建立常态化分层教育体系分为四类落地形式第一登录场景弹窗教育每次登录轮播展示新型钓鱼手法、官方渠道辨别方法禁止客户点击第三方链接登录第二高风险操作前置提示提现、设备绑定、账户信息修改前弹出钓鱼风险警示确认客户已阅读后方可继续操作第三周期性定向推送按月向客户推送本地钓鱼欺诈案例区分证券、虚拟资产两类差异化诈骗手段第四线上线下专题科普官网设立网络安全专栏线下投资者讲座讲解 Passkey 安全原理对比 OTP 漏洞风险。反网络钓鱼技术专家芦笛强调抗钓鱼技术仅能阻断技术层面的凭证窃取AI 生成深度伪造语音、高仿客服社交工程诈骗仍可诱导客户主动进行危险操作持续的投资者风险意识培育是防护闭环不可或缺的一环。9 结论与行业长期安全建设建议9.1 研究结论本文以 2026 年香港 SFC 强制性抗钓鱼认证新规为核心研究载体结合本地网络安全数据、FIDO2 技术标准、完整工程落地代码形成以下核心结论第一传统短信、邮件、App OTP 存在无法弥补的域名校验缺失漏洞在 AI 赋能的规模化钓鱼中继攻击下完全失效2025 年香港超半数网络安全事件由 OTP 漏洞引发监管层面强制淘汰具备充分现实风险依据第二Passkey 基于 WebAuthn 协议的本地域名绑定机制是原生抗钓鱼核心技术私钥本地硬件存储、每次认证独立随机挑战的设计从底层杜绝钓鱼网站窃取身份凭证的可能性是匹配 SFC 监管要求的最优落地方案文中完整前后端代码可直接支撑机构技术改造第三合规建设不能仅替换登录认证工具必须同步搭建登录、设备、交易提现三层实时风险监控体系配套标准化账户劫持应急处置流程、分层投资者安全教育形成 “预防 - 侦测 - 处置 - 教育” 闭环防护单一技术改造无法满足全部监管约束第四机构需按照 12 个月过渡期分三阶段推进改造区分增量新客户、存量老客户实施差异化引导管理层需承担账户安全最终主体责任内控缺失将直接面临监管问责与客户资产赔付第五互联网券商与 VATP 业务场景存在差异但 SFC 统一认证标准无豁免空间虚拟资产平台因资产划转匿名性需额外强化提现地址异常风控规则。9.2 行业长期安全建设建议推动行业统一抗钓鱼认证技术标准香港证券业、虚拟资产行业协会搭建共享风险数据库统一 Passkey 对接规范、风控告警规则降低中小型机构改造技术成本拓展多形态抗钓鱼认证载体除 Passkey 外普及 FIDO 硬件安全密钥针对高净值客户推出多凭证复合绑定方案进一步提升攻击门槛建立跨机构钓鱼欺诈联动预警机制券商、VATP 之间共享恶意钱包地址、钓鱼域名、欺诈客户特征提前拦截跨平台账户劫持攻击适配 AI 新型攻击迭代安全体系针对 AI 生成高仿短信、深度伪造客服语音诈骗新增行为生物校验、多渠道交叉身份核验机制持续更新风控模型完善监管常态化安全审计机制SFC 定期开展机构抗钓鱼认证落地专项核查对未按期完成 OTP 下线、风控体系缺失的机构采取业务限制、罚款等监管措施持续压实机构安全主体责任。9.3 研究局限性与未来研究方向本文研究局限集中于香港区域性监管政策下的线上证券、虚拟资产交易场景未覆盖传统线下经纪业务、银行持牌支付机构技术实现仅聚焦 Passkey 标准化 WebAuthn 方案未深入探讨硬件安全密钥批量运维体系。后续可进一步拓展研究方向第一对比全球各金融监管区域抗钓鱼认证政策差异形成跨境金融机构合规落地框架第二研究 AI 钓鱼攻击下抗钓鱼认证与行为生物识别融合技术方案第三量化测算券商、VATP 部署 Passkey 的改造成本、风险损失降低收益构建安全投入产出评估模型。结语2026 年香港证监会出台的抗钓鱼认证强制性新规是全球资本市场身份安全监管的标志性政策标志金融线上交易防护从 “补救式多因素验证” 转向 “原生防钓鱼前置防护”。钓鱼攻击依托 OTP 漏洞造成的客户资产损失、行业信任损耗倒逼监管与机构同步完成技术迭代Passkey 等 FIDO2 标准认证方案成为行业标准化安全底座。对于持牌互联网券商与虚拟资产平台而言12 个月过渡期不仅是技术改造窗口期更是重构账户安全全流程体系的契机。机构不能将合规简化为单纯替换登录验证工具需同步搭建实时风险监测、快速入侵响应、常态化投资者教育配套机制落实管理层安全主体责任形成完整风险防护闭环。反网络钓鱼技术专家芦笛指出网络安全防护不存在一劳永逸的技术方案机构需建立常态化安全迭代机制持续跟踪黑产攻击手段演变、新型抗钓鱼技术发展动态调整身份认证与风控策略才能长期抵御持续升级的钓鱼欺诈威胁保护客户资产安全、满足持续监管合规要求。编辑芦笛公共互联网反网络钓鱼工作组
