近年来，针对金融机构和其他组织的网络钓鱼攻击变得越来越复杂。“实时网络钓鱼”一种名为“网络钓鱼”的技术已成为一种严重威胁。这种攻击甚至会使一次性密码（OTP）失效，而一次性密码传统上被认为是防范网络钓鱼攻击的有效方法，这迫使金融机构彻底重新设计其身份验证基础设施。
本文阐述了实时网络钓鱼的技术结构以及应对实时网络钓鱼的技术“密码”的本质优势，并提出了未来需要考虑的政策问题。
什么是实时网络钓鱼？
实时钓鱼是一种攻击手段，攻击者充当用户和正规服务之间的“中间人”，利用用户输入的认证信息（用户名、密码、4 至 6 位的一次性密码 (OTP) 等）进行通信中继，并立即冒充用户。具体来说，即使 OTP 是通过短信或应用程序发送的，只要用户在钓鱼网站上输入，攻击者就能将其转发到正规服务的网站，并以用户身份登录。
这种类型的攻击中间人攻击（MitM）以外りも 中间人攻击（AitM） や 验证者冒充 它也被称为网络钓鱼，其特点是它在技术上在“看似真实的”网络钓鱼网站和真正的身份验证服务器之间进行中继。
中继服务器的完美欺骗
现代实时网络钓鱼攻击使用中继服务器通过复杂的方案欺骗用户，例如：
- 完成站点复制：实时读取真实网站（例如金融机构网站）的源代码，并生成一个视觉上无法区分的虚假网站（请注意，也存在这样的情况：当调用测试程序时，虚假网站会伪装成返回一个完全不同的网站，从而逃避测试）。
- 获取正确的 SSL 证书：提供看似合法的 HTTPS 连接
- 动态内容支持：登录后的个人信息显示也完全再现
中间人攻击 (AitM) 的工作原理
AitM 攻击遵循以下技术流程：
- 中继服务器安装：攻击者在真实站点和用户之间放置中继服务器。
- 动态响应生成：真实网站服务器的响应被修改并发送给用户
- 凭证收集：实时收集ID、密码、OTP及其他个人信息
- 执行合法访问：使用收集的信息立即访问真正的网站
在此次攻击中，攻击者同时扮演两个角色：
- 对于用户：充当真正的银行服务器（验证者模拟）
- 对于银行：像真实用户一样行动
这种双重身份冒充完全使网站（身份验证服务器）和用户之间基于传统“共享密钥”的身份验证方法（密码、OTP）失效。图 1 展示了这种关系。
（图1）AitM示意图
例如：
- 用户输入ID、密码和OTP
- 虚假网站将该信息转发到真正的身份验证服务器
- 身份验证成功，会话被劫持
OTP 为何失效
OTP（一次性密码）难以重用的代码因此，传统上它被认为是“安全的第二因素”。然而，在实时网络钓鱼等“中继攻击”中，如果攻击者可以代表真实用户使用它，即使只有一次，攻击也会成功。这使得它的“可抛弃”性失效。
此外，传统的基于 OTP 的多因素身份验证 (MFA)挑战-响应完整性验证（见下文）或 Web验证网站地址（域名）因为它没有用户无法知道他们的输入将会被发送给谁这就是为什么 OTP 本质上容易受到中继攻击的原因。
什么是密钥？
Passkey 是一种基于 FIDO2/WebAuthn 标准的身份验证技术。验证您正在访问的网站的地址（域）并发送用户身份验证所需的信息。1其主要特性如图2所示。
（图2）密钥特征
| 特点 | 说明 |
|---|---|
| 非对称密钥加密 | 身份验证通过使用公钥进行签名验证来完成。私钥不会发送给接收者。 |
| 原点绑定 | 身份验证请求与特定域绑定，因此难以中继或欺骗（来源检查和 RPID 检查 - 见下文）。 |
| 通过生物识别或 PIN 进行本地身份验证 | 用户身份验证在设备内部完成，无需向外部传输容易被克隆的身份验证信息，例如生物特征信息或 PIN。 |
| 防网络钓鱼 | 不要签署来自虚假网站的请求。 |
也就是说，如果用户意外访问了虚假网站，则身份验证器将不会向该网站返回真实网站的签名，因此攻击者将无法获取任何用于身份验证的信息。这是与 OTP 的一个关键区别。
Passkey 为何能抵御网络钓鱼？
密钥（FIDO2/WebAuthn）中继网络钓鱼 (AitM) 和域名欺骗反对具有结构抗性这是因为执行了三项检查：
（1）原产地验证
- 客户端（浏览器）发出身份验证请求网站来源（网站域名/地址）自动检测
- 这个起源是https:// + ドメイン名 + ポート番号 它包括
- 网站向浏览器发送的密钥认证请求包含网站的域名（RPID，见下文），但如果该域名与来源不同（例如，钓鱼网站），浏览器拒绝身份验证请求。并且不进行任何身份验证过程（子域名等例外）
- 此外，密钥认证结果中包含来源并发送到 Web 服务器，因此 Web 服务器也可以验证密钥认证是否在正确的网站上执行。
（2）依赖方身份（RPID）检查
- RPID 是服务器注册公钥时指定的域标识符
- 验证器（保存密钥的设备）搜索与收到的 RPID 关联的密钥是否存储在您的帐户中
- 如果RPID不同，则找不到私钥，也不会返回签名。
（3）挑战-响应
- 使用密钥进行身份验证时，Web 服务器会发送称为“质询”的随机数据
- 认证器使用其私钥对数据（包括质询）进行签名，并通过浏览器将其作为密码认证响应返回给 Web 服务器。
- Web 服务器验证响应中的质询是否由该会话的 Web 服务器发出。
- 如果攻击者创建任意挑战或者该挑战之前已被使用过，则 Web 服务器将拒绝该挑战。
为什么我们需要这三个？
图 3 总结了这种关系。
（图3）抵御网络钓鱼的三个必要要素
| 项目 | 角色角色 |
|---|---|
| 原产地检查 | 浏览器运行的网站保证合法性. 拒绝虚假网站 |
| RPID 检查 | 验证器密钥注册于哪个域名查看，防止滥用 |
| 挑战-响应 | 保证在当前会话中执行密钥认证，防止重复使用认证结果 |
只有一个是不够的， 只有当所有这些要素都到位时，才能实现“完全抵御网络钓鱼”します。
但密钥并非万能药
~利用注册流程进行网络钓鱼攻击的风险~
另一方面，密钥也不是万能的。与传统的 OTP 和密码相比，Passkey 更能抵御网络钓鱼。它作为一种显著提高用户身份验证安全性的手段而受到高度评价。
然而，抵御针对“凭证注册”的攻击取决于用户的判断和用户体验设计，攻击者强迫用户“注册”他们的密钥存在新的风险。
可能的攻击场景：攻击者“伪造”密钥并注册
攻击流程示例
- 攻击者创建了一个钓鱼网站（https://bank-login.example.org）
- 提示用户“您的身份验证已过期，请重新注册”。
- 用户使用传统的身份验证方法（密码或 OTP）在钓鱼网站上进行身份验证，并开始密钥注册流程
- 实际上，攻击者的身份验证器（设备）已经注册。
- 攻击者的密钥已在真实网站上注册
- 然后攻击者可以使用该密钥登录真正的网站。
从技术上讲，这是“合法注册”
- 在中继攻击中，WebAuthn 注册（navigator.credentials.create()）可以在攻击者的环境中执行，因此攻击者可以随意修改其内容。因此，从 Web 服务器的角度来看，注册本身无法与合法注册区分开来。
- 在中继攻击中，即使受害者的浏览器创建了包含钓鱼网站域名作为来源的密钥，攻击者也可以简单地丢弃结果并在攻击者的环境中重新生成包含合法域名的密钥，因此在受害者的浏览器中检查来源是无效的。
措施
图 4 总结了一些有代表性的可能措施，但并不详尽。
图4 针对欺骗的可能措施
| 措施 | 内容 |
|---|---|
| 加强注册前的身份验证步骤 | 通过要求使用公共个人身份验证或远程生物识别技术（如果可能）进行身份验证，或使用之前设置的密码重新进行身份验证来防止这种情况。 |
| 异常注册检测及通知 | 添加新密码时立即通知和确认（例如登录历史通知） |
可能的攻击场景：密钥认证后的会话劫持
近年来，有报道称，有人利用统称为“信息窃取程序”的恶意软件窃取密码和其他信息。这些恶意软件还可以获取会话 Cookie。密钥是一种保护措施，在用户身份验证后建立会话之前有效。会话建立后，密钥不再提供保护。
措施
作为针对会话劫持的对策，使用在设备的安全区域中生成的非对称密钥。设备绑定会话凭证 (DBSC) 此外，在此背景下，持续访问评估 （持续访问评估）也开始受到关注。
持续访问评估是一种超越传统一次性身份验证的安全方法，它持续实时监控和评估用户的访问权限。即使在用户登录后，它也会持续检查其位置、设备状态、行为模式、风险级别等。如果检测到异常活动或高风险情况，它会自动请求额外身份验证，并限制或阻止访问。
例如，如果出现来自非正常国家的访问或数据下载异常，我们可以立即做出响应。我们摒弃“一旦认证就安全”的前提，通过持续验证来加强安全性。
可能的攻击场景：针对剩余的密码认证漏洞
为了充分发挥密钥的防钓鱼功能，必须废除不具备防钓鱼功能的认证方式，转而使用密钥等具备防钓鱼功能的认证方式。即使引入密钥，如果仍然保留不具备防钓鱼功能的传统用户认证方式，用户仍然会成为钓鱼攻击的目标。
措施
相应的对策是消除这些传统的用户身份验证方法并仅使用密码。
然而，必须注意的是，由于各种因素，仍有用户难以使用密钥。在这种情况下，强制用户使用密钥可能会成为他们避免使用该服务的一个原因。因此，在保留现有身份验证方法的同时，可以采取替代措施，例如使用人工智能持续监控该会话作为高风险会话，并在检测到异常时停止交易。另一种选择是，在无法使用密钥的环境中，提供一个选项，允许在一定时间内（例如 15 分钟）使用密码登录，或者根据身份验证强度设置交易限制和权限（例如只读）。从这个角度来看，上述持续访问评估作为一项重要技术正备受关注。
结论：如果密钥没有经过“设计”，它就会被破解。
密钥是身份验证过程极其安全然而，如果注册流程被利用，攻击者可以注册一个强密钥。但这样做可能会适得其反。
因此，当金融机构和政府机构实施密钥时：
- 针对注册流程的安全设计，而不仅仅是身份验证
- 异常检测和恢复流程设计
- 基于钓鱼的UX设计和警告设计
因此，在采用一个系统时，在设计时必须考虑到这些因素。
政策影响：为什么现在需要密钥
1. 依赖 OTP 的法规和指南的局限性
在许多国家和地区，以 OTP 作为第二因素的多因素身份验证 (MFA) 仍然在 SCA（安全客户身份验证）要求中指定。然而，如上所述，使用 OTP 的多因素身份验证并不能保证抵御网络钓鱼基于此前提的安全法规可能已无法跟上攻击者的技术发展。与其指定“双因素身份验证”，不如思考应该应对哪些“威胁”。事实上，ISO/IEC 2 实体身份验证保证框架等都值得关注。2从那时起就一直如此。
2. 需要解决注册阶段的威胁
另一方面，需要牢记的是，密钥加强了身份验证方法使用阶段，因此也有必要应对身份验证方法注册阶段的威胁。
3. 纵深防御部分
虽然密钥是一种非常有效的用户身份验证手段，但在用户身份验证成功后，它对于会话劫持无效。因此，有必要将其与设备会话绑定和异常交易检测结合使用。
4.从消费者保护的角度促进传播
密钥不需要用户具备安全知识或小心谨慎，在终端侧透明地保证安全。不依赖安全教育的可持续措施这与消费者保护政策高度兼容。
从货币政策的角度看，单纯争论是否引入技术是不够的；什么算作“安全用户身份验证”标准本身也需要更新。在未来系统的设计中，使密钥等防网络钓鱼措施成为“常态”这对于确保金融消费者的安全和信任至关重要。3
[致谢]
在撰写本文时，出版商「关于密钥』他还是美国OpenID基金会的理事。小岩井浩介先生（X： @kocko野村综合研究所研究员，日本信息处理学会信息标准研究会SC27/WG5分委员会秘书，FIDO联盟与ISO/IEC JTC 1/SC 27/WG 5的联络官。古川英明先生, 『软件设计 2025 年 1 月刊他一直在积极地发表关于密码的文章，例如在杂志“特辑1：认证技术的最前沿：无密码认证“密码”的机制和实现”的前半部分。伊藤亮（X： @ritou我们向那些给予我们如此合作的人表示诚挚的谢意。
一个评论