波仔
🛡️ 第一章 信息安全的基本概念
📄 一句话概括

一次性口令解决"偷到一次就用不了第二次"，多因子认证解决"偷到一个因子还不够"；两者都依赖一条铁律——因子必须不同类。

📝 本节和前面几节的关系

上一节（针对密码的攻击）的结论有点让人沮丧：单靠口令，怎么设都有破的口子。这一节就是答案的下一层——在口令之外再加一样东西。

它接的是上一节末的那句：口令的复杂度收益有限，真正把攻击成本抬高一个量级的，是加一个"偷不走的因子"。

一、一次性口令：让"偷到"这件事贬值

一次性口令（OTP）的意思是：这个口令只能用一次，用过就失效。

它最直接的价值是把"偷"这件事贬值了：

一次性口令的常见实现有两种，区别值得知道：

形式 怎么生成 特点
基于时间（TOTP） 手机上的认证器 App 每 30 秒算一个新码 不依赖网络和运营商，最常用
基于短信 服务器发一条短信 方便，但短信通道本身可被攻击

短信验证码的软肋必须单独说清：它可以被"实时转发"——攻击者做一个假登录页，你输入口令后，他把请求转发给真网站，网站发验证码给你，你输入，他立刻用它登录。整个过程你可能完全察觉不到。除此之外，补办手机卡、短信劫持也是现实手段。

所以主流看法是：短信验证码好过没有，但不是理想的第二因子——能换成就换成认证器 App 或硬件密钥。

二、多因子认证：关键在"不同类"

多因子的定义容易讲错。它的要求不是"两步"，而是"两类"：

因子类别 是什么 例子
你知道的 知识 口令、PIN
你拥有的 物品 手机、硬件密钥、工牌
你本身的 生物特征 指纹、人脸

必须来自不同的类别，才算多因子。

所以下面这些都不算：

而真正的强多因子，是口令 ＋ 硬件密钥这类组合——它不但跨了类别，还有一个额外的好处：能抗钓鱼。

三、为什么硬件密钥能抗钓鱼

这是本节最重要的一个技术点。

短信码和动态码都能被"转发"：假页面骗你输入，攻击者拿着你的输入去真网站用。

硬件密钥不能。原因是它和网站之间有一个绑定关系：硬件密钥在响应时，会把"当前访问的是哪个网站"（域名）算进签名里。所以你登录假域名时，密钥算出来的响应在真网站那边对不上——攻击者拿到也没用。

这个机制叫源绑定。它把"抗钓鱼"从"靠用户眼力"变成了"靠密码学保证"——用户就算看错了域名，也登不进去。

这也是为什么主流指南把硬件密钥/通行密钥称为抗钓鱼的认证方式，并且明确说短信验证码不是。

四、多因子的价值到底有多大

一句话讲清多因子的作用：

它让你的账号从"一个秘密"变成"一个秘密 + 一件东西"。

对攻击者的影响是连锁的：

但多因子不是万能的，也有它的短板：

  1. 有成本：用户要带设备、要操作一步；企业要部署、要处理"设备丢了怎么办"。
  2. 有恢复难题：设备丢了、换手机了怎么办？恢复流程往往是最弱的一环——很多攻击最终是从"找回账号"这一步进去的。
  3. 有的场景不适用：共享账号、无人值守的设备、自动化程序，都不能"掏出手机点一下"。

所以多因子的正确用法是分场景：高价值、可交互的账号（邮箱、财务、云控制台）必开；低价值的、机器用的账号用别的办法（凭据托管、密钥轮换）。

五、动手 Demo：六种登录方式的对照

下面这个 Demo 把几种常见组合放进同一张表，看它们各自能挡住什么。

# (方式, 抗撞库, 抗钓鱼, 抗偷看, 便利, 难共享)
# 强度分 = 抗钓鱼×3 + 抗撞库×2 + 抗偷看×1

实跑输出：

================================================================================================
一、六种登录方式的能力对照
================================================================================================
  方式                          抗撞库  抗钓鱼  抗偷看  便利  难共享
  --------------------------------------------------------------------------------------------
  只用口令                      ❌       ❌       ❌       ★★    ★
  口令 ＋ 短信验证码            ✅       ❌       ❌       ★     ★★
  口令 ＋ 认证器 App 动态码     ✅       ✅       ❌       ★     ★★★
  口令 ＋ 硬件密钥（FIDO2）     ✅       ✅       ✅       ★     ★★★★★
  通行密钥 Passkey（免口令）    ✅       ✅       ✅       ★★    ★★★★★
  只用短信验证码（无口令）      ❌       ❌       ❌       ★★    ★

================================================================================================
二、逐条点评（按防护强度排序）
================================================================================================
  口令 ＋ 硬件密钥（FIDO2）     强度 6/6    绑定域名，钓鱼页上根本用不了
  通行密钥 Passkey（免口令）    强度 6/6    本机生物识别解锁，没有可偷的口令
  口令 ＋ 认证器 App 动态码     强度 5/6    动态码不落短信，钓鱼难度高很多
  口令 ＋ 短信验证码            强度 2/6    能挡撞库；拦不住实时转发的钓鱼页
  只用口令                      强度 0/6    最常见的形态，也是最薄的一层
  只用短信验证码（无口令）      强度 0/6    单因子，换号即失守

  ④ 一次性口令的价值在【一次性】三个字上：
     它让【这一次偷到的】变成废纸。但它不解决【当场被引导着交出去】。
  ⑤ 多因子的价值在【因子不同类】上：
     知道的（口令）＋ 拥有的（设备）＋ 你本人（指纹）。
     同为【知道】的两样，比如【口令 ＋ 密保问题】，不算多因子。

  ⑥ 表里最刺眼的一行是【只用短信验证码】：
     它看着像多因子，其实是单因子——而且这个因子还能被补办手机卡拿走。
     2026 年的共识是：能把可被钓走的因子（短信码）换成钓不走的（硬件密钥、通行密钥），就换。

读这个输出：注意 口令 ＋ 短信验证码 这一行——它抗撞库是 ✅，抗钓鱼是 ❌。这正是它现在的位置：它是明显好过"只用口令"的一步，但不是终点。 再看最后一行 只用短信验证码（无口令）：它看着像"用了短信很先进"，其实是单因子，而且换号即失守。

六、⚠️ 2026 现状

30 秒实验

打开你最重要的三个账号（邮箱、支付、云盘）的设置页，找"安全 / 登录 / 两步验证"，做三步：

  1. 看现在开的是什么：没有开 → 这是第一优先级；开的是短信 → 可以升级。
  2. 升级到认证器 App（如果手机支持）：扫描二维码即可，一般两分钟完成，同时会给你一组恢复码——把它抄下来离线保存。
  3. 如果条件允许，再上一个通行密钥：在同一页附近通常就有入口。

做完之后，你会发现"抗撞库"这件事基本不用再担心了。

常见误区

  1. 错误：开了短信验证码就是多因子了，安全了。——纠正：短信验证码形式上是第二因子，但它是可被实时转发的——假页面上输入口令，攻击者同步转发，验证码就落在他手上。它能明显提高门槛，但不是"抗钓鱼"的方案。

  2. 错误：验证码每 30 秒换一次，所以很安全。——纠正：换得快不等于钓不走。动态码的问题不在有效性长，而在它可以被当场转交。只有把凭据绑定到访问的站点上，才能从根上堵住这条路。

  3. 错误：口令 ＋ 密保问题就是双保险。——纠正：密保问题属于"你知道的"，和口令是同一类，不构成多因子。而且这些问题的答案往往能在社交平台上查到，比口令更弱。主流指南已经明确不建议使用。

  4. 错误：上多因子太麻烦，我们人少、不划算。——纠正：多因子的成本可以分层控制——对最关键的三五个账号必开，其他暂缓。而且很多场景下"麻烦"可以通过选择更顺手的因子来降低（比如通行密钥其实是比输口令更省事的登录方式）。

自测三问（点开对答案） 1. 为什么"一次性"这三个字能提高安全性？ —— 因为它让**被偷到的那次凭据立刻作废**。攻击者看到、截获、翻到的那一串码，下次登录时已经无效。**它把"偷"的收益从"长期可用"降到"一次机会"。** 2. 为什么硬件密钥不怕钓鱼页面？手机上的动态码为什么怕？ —— 硬件密钥在响应时会**把访问的域名绑进签名**，所以登录假域名时产生的响应在真网站上通不过——这是密码学保证的，**不依赖用户是否看清了域名**。而动态码只是"一串数字"，用户在哪输入它就落到哪，**钓鱼页面照样能收走并实时转发**。 3. 部署多因子时，为什么"恢复流程"要和控制措施一起设计？ —— 因为**恢复流程是绕过认证的唯一正当路径**——设备丢了、换手机了、员工离职了，都要走它。如果这条路的验证比正常登录更弱，攻击者就会专攻它。**认证越强，恢复流程就越要按同样的标准设计。**

相关笔记