当前位置：首页 > news >正文

告别传统密码：FIDO2 与 WebAuthn 如何从物理层面终结钓鱼攻击？

news 2026/7/30 6:41:39

只要身份认证的实质依然依赖“人类可记忆与输入的字符串”，无论规则制定得多么复杂（大小写字母、特殊符号或强制定期更换），凭据泄漏与钓鱼攻击的风险就无法彻底抹去。

无密码认证（Passwordless Authentication）的终极目标，并非仅仅提升登录体验，而是从现代安全体系中彻底剥离人类记忆的字符串，用**公钥密码学（Asymmetric Cryptography）**重建身份信任的基石。

传统密码体系的致命缺陷

根据安全研究机构的统计，超过 80% 的企业数据泄露事件都与凭据盗用相关。传统密码在面对现代黑客攻击手段时表现得不堪一击：

凭据猎取（Phishing & 鱼叉钓鱼）：攻击者通过搭建像素级复刻的伪造网站，诱导用户主动敲入密码。
凭据填充（Credential Stuffing）：由于绝大多数用户会在多个平台重复使用相同或相似的密码，某一小网站的数据泄露常引发大面积的撞库风暴。
SIM 卡劫持与短信漏洞：基于 SMS 验证码的二次认证（2FA）早已不安全，攻击者可通过 SIM 换卡攻击（SIM Swapping）或伪基站实时截获验证码。
算力碾压下的暴力破解：分布式计算与 GPU 算力的暴涨，使得常见哈希算法保护下的弱密码在短时间内就能被穷举破解。

要解决这些根源性缺陷，唯一的解法就是让客户端不握有密码，服务端也不存储密码。

核心基石：FIDO2、WebAuthn 与 Passkeys

以 FIDO2 和 WebAuthn 为核心的无密码标准，彻底改写了凭据生成与存储的底层架构。

1. 秘钥对在硬件安全芯片中生成

当用户在某个网站注册无密码凭据（Passkey）时，设备（如 MacBook 的 Touch ID、iPhone 的 Face ID 或硬件 Key 如 YubiKey）并不会生成任何字符串密码。相反，设备会在本地的**硬件安全芯片（TPM / Secure Enclave）**中生成一对专属于该网站的椭圆曲线公私钥对（如 ECDSA P-256 或 Ed25519）。

2. 私钥严格保密且永远离线

私钥被封存在本地安全芯片内，受到硬件级隔离保护。私钥绝不会离开设备，绝不出芯片，也绝不会上传至任何云端服务器或第三方平台。

3. 服务端仅保存公钥

客户端在注册阶段仅将生成好的**公钥（Public Key）**发送给应用服务器并存入数据库。由于公钥完全公开且仅用于验签，即便服务端的凭据数据库发生全量泄露，攻击者也无法反向推导出私钥。

无密码登录与 Challenge-Response 鉴权流程

在日常使用中，用户无需记忆任何密钥，所有的认证逻辑都在后台通过严密的密码学质询与响应完成。

完整的登录鉴权可以拆解为三个步骤：

阶段 1：服务端下发质询码（Challenge）

当用户点击“无密码登录”时，服务端会即时生成一段高熵值的随机字节串（Challenge 质询码），并连同服务商标识（RP ID）发送给客户端浏览器。

// WebAuthn 客户端发起鉴权请求示例constpublicKeyCredentialRequestOptions={challenge:newUint8Array([/* 服务端生成的随机字节 */]),rpId:"example.com",userVerification:"required",// 强制需要生物识别或 PIN 解锁timeout:60000};// 调起设备本地安全组件constassertion=awaitnavigator.credentials.get({publicKey:publicKeyCredentialRequestOptions});

阶段 2：本地生物识别解锁私钥

客户端浏览器接收到质询后，调起系统的安全 API。此时，设备会要求用户刷指纹、面容或输入设备 PIN 码。这一步的作用仅发生在设备本地——用于向硬件芯片证明“当前操作者是设备所有者”，进而解禁芯片内部私钥的调用权限。

阶段 3：签名与服务端验证

硬件芯片解锁后，使用私钥对“服务端质询码 + 客户端上下文”进行数字签名，并将签名结果回传给服务端。服务端取出预先存储的公钥对签名进行解密校验。若解密数据与先前下发的 Challenge 匹配，身份确认，登录成功。

防钓鱼机制：Origin 域名强绑定

在所有的安全特性中，WebAuthn 对抗钓鱼攻击的机制最为彻底。

传统 MFA（如 OTP 动态口令、短信验证码）在面对高级钓鱼时依然可能失效：攻击者可以搭建一个伪造网站，实时接收用户输入的动态口令并中继给真实服务端。

而 WebAuthn 规范要求：浏览器与操作系统在打包 ClientData 并交由硬件芯片签名时，会由底层强制填入当前访问的实际域名 Origin（如https://login.fake-bank.com）。

JavaScript 无法伪造 Origin：浏览器底层保证了 Origin 的绝对真实性，网页代码无法篡改该字段。
私钥绑定作用域：硬件安全芯片只允许匹配特定 Origin 的私钥参与签名。
验签天然失败：即便用户在钓鱼网站上刷了指纹，生成的签名中包含的也是钓鱼网站的域名。攻击者将该签名发给真实服务端时，服务端核对 Origin 不符，验签立即失败。

这种在协议层建立的域名绑定约束，从物理和密码学层面彻底摧毁了钓鱼攻击的生存土壤。