金融机构的双因素认证（一）：一把强度尺

TL;DR

这是《金融机构的双因素认证》系列的第一篇。系列锚定金融机构的两类典型场景：内部落地系统（机构自建、内部/员工直接使用的系统）和专线托管端系统（通过专线接入的外部托管系统），并按认证方案分篇，逐一讲清原理，并对比同一方案在两种场景下的差异。

这一篇不讲任何具体方案，只做两件事：定义清楚两种场景到底差在哪，以及立一把贯穿全系列的认证强度分级尺。后面七篇会反复用这把尺子给每种方案定位。

1. 互联网 2FA（Chen 注：2FA 即 Two-Factor Authentication，双因素认证的英文缩写，本系列标题里的「双因素认证」和正文里的 2FA 指的是同一件事。） 的默认假设，在这里大多不成立

打开任何一篇讲双因素认证的科普文章，背后几乎都藏着同一组假设：

• 终端不可控：用户用自己的手机、自己的电脑，服务方管不到这台设备装了什么、有没有被入侵
• 网络不可信：请求要经过公网，中间人攻击、DNS 劫持、钓鱼站点都是常态威胁
• 体验优先于强度：用户随时可能放弃注册、放弃登录，认证方案输在「麻烦」上就等于输了

这组假设催生了互联网世界最流行的几种方案：短信验证码（利用用户本来就有的手机号）、推送确认（利用用户本来就装了的 App）、后来的 Passkey（Chen 注：Passkey 基于 WebAuthn/FIDO2 标准，把私钥存在用户设备的安全芯片里，用生物识别或设备 PIN 解锁使用，免去了记密码和输验证码的步骤。2022 年后由苹果、谷歌、微软联合推动，是目前互联网行业主推的下一代认证方式。）。它们的共同特点是：尽量利用用户已经拥有的东西，因为要求用户额外购买、携带一个专用设备，在互联网场景下几乎等于劝退。

金融机构的两类典型场景，前提常常是反过来的：

前提一反转，评估标准就要跟着换。短信验证码在互联网上是「够用的默认选项」，但如果终端本来就受控、网络本来就有额外信任层，还要不要为了那点「方便」去承担短信通道固有的弱点？这类问题会贯穿整个系列，第一步是先把「两类场景」这件事定义清楚。

2. 两个场景：内部落地系统与专线托管端系统

一是内部落地系统。机构自己建设、自己运维，供内部人员（员工、内部运营团队）直接使用的系统。典型例子是核心交易系统、内部风控后台、运营管理系统。这类系统的终端通常是机构统一采购、统一配置的办公设备，用户身份由机构自己的身份系统（IAM）（Chen 注：IAM 即 Identity and Access Management，身份与访问管理系统，负责用户身份的创建、认证、授权和生命周期管理，是企业内部系统统一管控账号权限的基础设施。）颁发和管理，合规责任完全在机构自己身上。

二是专线托管端系统。机构通过专线接入的、托管在外部机构的系统。典型例子是交易所的交易终端、清算机构的对接系统、云托管商提供的 SaaS 化金融基础设施。这类系统的终端可能是机构自己的设备，也可能是托管方要求使用的专用终端；网络走的是专线而非公网，但专线连接的是两个不同的信任主体；用户身份可能由托管方颁发，也可能是机构身份联合托管方的准入策略；合规责任由机构和托管方共同承担，边界需要在协议里划清楚。

表面上看，两者都比互联网场景「更受控」，但受控的程度和受控的主体不一样。内部落地系统的信任边界完全在机构自己手里，专线托管端系统的信任边界横跨两个机构，专线只解决了「网络层不是公网」这一件事，并没有解决「对面那台终端到底是谁在操作」这个问题。这个区别，是后面每一篇对比两种场景时反复要回指的地方。

3. 威胁模型：谁在攻击，从哪里攻击

威胁模型不一样，认证方案要防的东西也不一样。

内部落地系统的主要风险来自：

• 内部人员越权：员工本人账号被盗用，或员工本人恶意操作超出权限的功能
• 终端被控制：办公设备中木马、被横向渗透，攻击者拿到的是一台「合法但已失陷」的机器
• 供应链风险：办公软件、驱动、外设固件里被植入的后门

这些风险的共同点是：攻击者拿到的往往已经是一个「看起来合法」的起点（合法员工身份、合法办公设备），认证要解决的问题是在这个起点之上再加一道很难被绕过的门槛。

专线托管端系统的主要风险来自：

• 专线两端的信任转移问题：专线证明了「这条链路是专的」，但不能证明「链路那头操作的人是谁」，专线本身不是认证
• 托管方运维人员的风险：托管方内部人员的权限管理，机构自己管不到，只能靠协议和审计约束
• 多租户共享基础设施的隔离问题：如果托管方用同一套基础设施服务多个机构客户，一个客户侧的认证漏洞可能被用来横向影响其他客户

4. 什么是「因素」：双因素认证的基本定义

在往下讲强度分级之前，有必要先讲清楚「因素」（factor）到底指什么，因为这是后面几篇最容易被混淆的地方。

认证因素通常分三类：

• 你知道的（something you know）：密码、PIN 码
• 你有的（something you have）：手机、硬件令牌、USB Key、智能卡
• 你是的（something you are）：指纹、人脸等生物特征

双因素认证要求两类不同类别的因素组合，而不是「两个东西」就算数。密码+安全问题都是「你知道的」，本质上仍是单因素；密码+硬件 OTP 令牌才是真正的两类因素组合。这条定义会在第 2 篇讲短信验证码时派上用场。短信验证码严格来说算「你有的」（拥有那个手机号/SIM 卡），但它的强度和硬件 Token 完全不是一个量级，这正是分级尺存在的意义。

专线场景下「网络层信任」（第 7 篇的主题）不属于上面任何一类因素，它更像是一种环境层面的加成，不能单独构成一个因素，但会影响整体认证强度的评估。这也是为什么第 7 篇要单独成篇，而不是塞进某个具体方案的场景对比里。

5. 认证强度分级尺

有了因素的定义，接下来需要一把能给不同方案「打分」的尺子。这里借用 NIST SP 800-63B（Chen 注：NIST（美国国家标准与技术研究院）在 SP 800-63B《数字身份指南：认证与生命周期管理》里，把认证保证级别（Authenticator Assurance Level，AAL）分成三级：AAL1 允许单因素；AAL2 要求双因素，且限制因素的实现方式（如短信验证码在部分场景下被限制使用）；AAL3 要求基于硬件的加密认证器，能抵抗验证者伪冒攻击。这是目前业界最常被引用的认证强度分级框架之一。） 的 AAL 分级思路，改造出本系列自用的三级尺：

不过确实存在一条能直接对上号的国内条文。GB/T 22239-2019（Chen 注：全称《信息安全技术 网络安全等级保护基本要求》，2019 年 5 月发布、12 月 1 日实施，是「等保 2.0」体系里的核心标准，替代了 2008 版的等保基本要求。配套的《网络安全等级保护测评要求》（GB/T 28448-2019）从测评方法（访谈、核查、测试）的角度对应同一套安全要求，但本文只引用基本要求里能核实到的这一条原文，不展开测评要求的具体条款。） 对第三级系统的身份鉴别，第 8.1.4.1 条明确写道：

这条条文正好落在本系列 L2 级的定义上：要求真正的双因素（不是密码+安全问题那种同类因素的组合），且强制其中一种基于密码技术实现。这把纯生物识别（如仅指纹）、纯短信验证码排除在「合规达标」的组合之外，因为它们单独都不构成「密码技术」意义上的鉴别技术。达到 L3（私钥不出硬件）在等保条文里没有单独更高的强制要求，是机构自愿在 L2 基础上做的加码。

多数金融机构的核心业务系统按定级要求至少落在第三级，这条条文因此几乎是所有内部落地系统绕不开的底线要求；专线托管端系统的定级和测评责任划分更复杂（谁来定级、谁承担测评义务），会在第 7 篇具体展开。

除了强度这一个维度，后面每一篇评估方案时还会用到另外三个维度：

• 合规约束：这个方案是否存在被明文限制/不推荐使用的场景，是否需要额外的审计留痕
• 可用性：终端要求、部署和日常使用的便利程度
• 成本：硬件采购、发放、更换、运维的综合成本

四个维度合在一起，构成本系列反复使用的评估框架：强度、合规、可用性、成本。不会存在一个在四个维度上都最优的方案，每一篇要讲清楚的正是具体的取舍在哪。

6. 这个系列接下来要讲什么

框架搭好了，后面七篇按认证方案逐一展开，每篇都会按同一个结构走：原理 → 内部落地系统怎么用 → 专线托管端怎么用（差异点）→ 已知弱点 → 在这把强度尺上的定位。

• 第 2 篇：短信验证码（一个被反复质疑的方案）
• 第 3 篇：硬件动态口令（仍是主力）
• 第 4 篇：手机动态口令（从硬件到软件的动态口令）
• 第 5 篇：数字证书与硬件密钥（智能卡、USB Key 与 HSM）
• 第 6 篇：生物识别（作为第二因素的信任边界）
• 第 7 篇：专线场景特有方案（托管端接入的信任模型）
• 第 8 篇：选型决策矩阵（从合规等级倒推方案组合）

下一篇从短信验证码开始，它是互联网世界最流行的第二因素，也是这个系列里第一个要被认真质疑的方案。