主题
第 5 章 密码与认证
本章导读:账号是数字身份的入口,密码与认证就是入口上的锁。一旦这把锁失守,网银、邮箱、社交、政务、云盘账号会像多米诺骨牌一样全线暴露。本章回答三个问题:怎么设置一把够强的锁(密码)?怎么给锁再加一道独立的保险(二次验证)?以及为什么新一代"通行密钥"正在让密码本身变得多余。按 🟢🟡🔴 三级读完,你可以立刻动手把核心账号的认证强度提升一个量级。
🟢 基础:先认识"锁"——为什么弱密码是最致命的脆弱性
回顾第 3 章的纵深防御五层模型,第 2 层就是"认证(强密码 + 2FA)"。对普通人来说,这是投入产出比最高的一层——一次设置,长期受益,挡住绝大多数批量攻击。我们先从三个最基本、零成本、几分钟内就能做完的动作开始。
1. 密码长比复杂更重要
很多人以为 "P@ssw0rd1!" 这种混合大小写 + 符号 + 数字的密码很强,这是一个普遍的误解。衡量密码强度的核心指标是"熵"(entropy),直观理解就是"可能的组合总数"。我们来算两笔账:
- 12 位纯小写字母的组合数约 26¹² ≈ 9.5 × 10¹⁶
- 8 位混合字符(大小写 + 数字 + 符号,约 70 个可选字符)的组合数约 70⁸ ≈ 5.8 × 10¹⁴
12 位纯字母的强度远超 8 位看似复杂的密码。换句话说,把密码从 8 位加到 12 位,比把符号换成更花哨的字符有用得多。这就是第一条原则:长度优先于复杂度。
可操作建议:用"密码短语"(passphrase)的方法生成密码——挑 4–5 个互不相干的词拼成一句,长度自然够、好记、熵充足。例如:大象吃键盘云朵很安静(15 位)、blue-coffee-window-river(23 位)。避免使用生日、手机号、姓名拼音、配偶孩子名字、连续键盘按键(qwerty、12345678)——这些都在公开的"常见弱密码榜单"里,攻击者的字典会优先尝试。
📌 数据标注:每年 security.org、NordPass 等机构发布的"年度最常见密码榜单"中,
123456、password、qwerty、00000000几乎常年占据前列,反映大量用户仍未改用强密码。来源性质:厂商报告,估算。
2. 绝不在多个重要账号上复用同一密码
这是普通人最容易犯、也是后果最严重的错误。其背后的机制叫撞库(Credential Stuffing):
- 你在 A 网站注册时用
邮箱 + 密码X。 - A 网站某天数据库泄露(无论因外部攻击还是内部失守),
邮箱 + 密码X这份清单流出到灰色市场。 - 第 3 章第①类威胁主体(诈骗与犯罪分子)拿着这份清单,用自动化脚本去 B、C、D……网站批量尝试登录。
- 如果你在 B、C、D 都用同一个
密码X,他们就成功了。
据公开聚合项目(如 Have I Been Pwned)的累计统计,截至约 2025 年,已公开泄露的"邮箱 + 密码"凭据条数累计已达百亿量级(估算,来源性质:第三方聚合,待复核)。国内多起大规模账号被盗事件,源头都可追溯到撞库。
最低要求(立刻可做):以下核心账号,每个都必须有互不相同的密码——
- 主邮箱(找回一切账号的"万能钥匙")
- 网银与支付(银行 App、支付宝、微信支付)
- 手机云账号(Apple ID / 华为 / 小米 / OPPO / vivo 等,关系到设备查找、云备份、应用商店消费)
- 主用社交账号(微信、QQ、微博)
- 政务与身份账号(交管 12123、个人所得税、国家反诈中心、本地政务 App)
- 主用购物平台(淘宝、京东、拼多多)
至于那些"丢了也无所谓的"小论坛、临时注册站,可以用一个单独的"低价值密码"统一应付,前提是这个密码不出现在上述任何核心账号上。
更彻底的解法见 🟡 进阶——密码管理器,让你真正做到"每个账号一个独立、超长、随机的密码"。
3. 立即给重要账号开启"二次验证"(2FA)
二次验证(2FA,Two-Factor Authentication,又称双重认证、两步验证)的意思是:登录时,除了密码(你知道的东西),还要再加一个"你拥有的东西"或"你本身"——例如手机上每 30 秒变化的一次性验证码、指纹、U 盾、硬件密钥。
为什么必开?因为它把"密码泄露"和"账号被盗"之间的因果链切断了——即使密码已经泄露,攻击者也登不进去,因为他拿不到第二因素。
按账号价值排序,优先为以下账号开启 2FA:邮箱 → 支付 → 云账号 → 社交 → 政务 → 购物(与上节核心账号清单一致)。
开启入口示例(界面名称可能随版本更新而调整,以实际为准):
| 服务 | 开启路径(约 2026 年,待复核) |
|---|---|
| 微信 | 我 → 设置 → 账号与安全 → 登录设备管理 / 微信密码 |
| 支付宝 | 我的 → 右上角设置 → 安全中心 → 安全设置 |
| Apple ID | 设置 → 点你的姓名 → 登录与安全性 → 双重认证 |
| Google 账号 | myaccount.google.com → 安全性 → 两步验证 |
| 银行 App | 各行路径不一,通常在"我的 → 安全中心 → 登录验证方式" |
⚠️ 重要:开启 2FA 后,务必按 🟡 进阶"备用恢复码"一节保管好恢复码——否则一旦手机丢失,你可能反而把自己锁在外面。
🟡 进阶:用密码管理器 + TOTP 构建可维护的认证体系
基础三件事做到了,你已经挡住 90% 以上的批量攻击。但如果你有几十上百个账号,"每账号一个独立长密码"靠人脑根本无法维持。这一节给你一套可长期维护的工程方案。
1. 密码管理器:让"每账号独立、超长随机密码"成为现实
密码管理器的核心思路:用一个"主密码"保护一个强加密的本地数据库,数据库里存储你所有账号的随机长密码。你只需记住主密码这一把"钥匙中的钥匙",其余全交给工具。
三类选型对比
| 类型 | 代表产品 | 优点 | 缺点 | 适合谁 |
|---|---|---|---|---|
| 本地存储(开源) | KeePassXC | 数据库文件完全自控,可放任意云盘同步;源码可审 | 跨设备同步需自行搭建;移动端体验一般 | 技术爱好者,追求极致自控 |
| 云同步(开源) | Bitwarden、Proton Pass | 全平台自动同步,免费版即可用;源码可审;可自托管 | 云端存有加密副本(强加密),需信任服务商基础设施 | 多设备用户,首选 |
| 云同步(闭源) | 1Password、Enpass | UI 精致、生态完善、客户支持好 | 闭源,订阅费用较高 | 重视体验、愿付费读者 |
选型原则:优先开源 + 可导出 + 可自托管或可迁移。这样即使服务商停摆或涨价,你的数据不会被绑架——这与第 1 章八项权利中的"可携带权"(第 45 条)精神一致:你的账号清单与凭据属于你的个人信息,你有权复制、迁移。
标准使用流程(约 30 分钟起步,长期受益)
- 选定一款产品,在主电脑和手机上分别安装客户端。
- 设置主密码——这是整个密码库唯一的"钥匙中的钥匙",必须满足:15 位以上、密码短语式、绝不在任何其他地方使用、写在纸质本子上锁进抽屉作兜底。一旦遗忘,没有任何后门可恢复(这正是它安全的原因)。
- 为密码管理器本身开启 2FA(若产品支持),形成"主密码 + 第二因素"双保险。
- 逐个为重要账号生成新密码并替换:在密码管理器中点击"生成密码",设为 16–32 位随机字符(大小写 + 数字 + 符号),保存后去对应网站修改密码并登录验证。可分批进行,不必一天完成。
- 定期备份:本地类(如 KeePassXC)复制
.kdbx数据库文件到 U 盘、加密云盘等多处;云同步类每月导出一次加密 JSON 备份到本地。
⚖️ 法律视角:密码库里的账号清单本身属于你的个人信息(部分还涉及敏感个人信息,如金融账户、支付账号)。依据《个人信息保护法》,你享有查询、复制、可携带的权利;选可导出、可迁移的产品,本质是在行使这些法定权利(参见第 1 章"八项权利")。
2. TOTP 验证器 App:比短信验证码更安全的二次验证
二次验证的"第二因素"主要有两种实现:
- 短信验证码(SMS OTP):服务商把 6 位数字以短信发到你手机上。
- TOTP(Time-based One-Time Password,基于时间的一次性密码):你手机上的验证器 App 与服务端共享同一个"种子密钥",双方基于当前时间和种子,按同一套算法独立计算出一串每 30 秒变化一次的 6 位数字。服务端看到你输入的数字与它算出的一致,即放行。整个过程不经过短信通道。
TOTP 普遍优于短信验证码的原因:
- 短信可被劫持:SIM 卡冒补、伪基站、信令网漏洞等机制都可能让短信验证码落到他人手里。相关机制详见第 13 章,此处仅指出结论——短信通道本身是一条相对脆弱的通道。
- 抗钓鱼更强:部分 TOTP 实现绑定特定域名,假站点无法套取有效码。
- 离线可用、速度更快:只要手机时间准确,无需等短信。
切换建议(可操作步骤):
- 登录服务商的"安全设置"或"两步验证"页,若同时提供"短信"和"验证器 App(身份验证器)",优先选验证器 App。
- 启用过程中页面会显示一个二维码,用验证器 App 扫描即可绑定;部分服务还会显示一串文本种子,作为二维码无法扫描时的备选。
- 绑定成功后,务必先下载或抄写页面上显示的"恢复码"(见下一小节),再做任何其他操作。
- 在验证器 App 中为条目设置图标和备注,便于快速识别。
- 验证器 App 本身建议开启"应用锁"(生物识别或独立 PIN),防止手机丢失后被打开。
常见免费验证器 App(均跨平台,中性列举):
- Microsoft Authenticator:支持云备份,换机方便(iOS/Android)。
- Google Authenticator:简单稳定,近年已支持云同步。
- 2FAS:开源,数据不上传,隐私友好。
- Bitwarden / Proton Pass 内置验证器:与密码管理器集成,一站式管理。
⚠️ 取舍提示:若你的手机号本身存在冒补风险(参见第 4 章"手机号与账号"),把重要账号从短信验证码迁到 TOTP 尤其紧迫。短信 2FA 比不开 2FA 强,但 TOTP 又比短信 2FA 强一档。
3. 备用恢复码:被忽视的"逃生通道"
几乎每一个提供 2FA 的服务商,在开启 2FA 时都会给你一组备用恢复码(Backup Codes / Recovery Codes),通常 10 个左右,每个 8–12 位随机字符串。
它们的作用:当你丢失手机、验证器 App 被误删、号码无法收短信时,用任一恢复码即可登录,每个码用一次即失效。它们是防止你把自己锁死的最后一道兜底。
为什么必须妥善保存:
- 不存 → 手机丢失时,你可能彻底无法登录邮箱、云账号、支付,陷入漫长而痛苦的客服申诉。
- 存在手机备忘录里(明文)→ 手机丢了等于没存,甚至更糟(恢复码随手机落入他人之手)。
保存方法(三选一,或组合):
- 纸质打印 / 手抄 + 实体安全处(保险柜、家用文件盒、与重要证件放一起):对抗所有网络攻击,只对物理入侵脆弱。这是最朴素也最稳的方式。
- 加密文件存云盘 + 纸质备份:双重保险,网络与实体各一份。
- 存进密码管理器:为恢复码单独建一个条目(如命名
[账号] 恢复码),与该账号的密码条目区分开。
📌 重要细节:每次重新生成恢复码(如重置 2FA、换手机后重新绑定),旧恢复码立即全部作废。请同步作废旧纸质备份,以免紧急时抓到一堆失效的码。
🔴 深度:从"锁"到"无锁"——通行密钥与密码存储的底层机制
愿意深入一层的读者,这一节回答两个根本问题:为什么密码这种"锁"本身正在被新一代技术取代?服务商到底是怎么存你密码的,这决定了泄露后果有多严重?
1. 通行密钥(passkey / WebAuthn):让密码不再成为攻击面
密码体系有一个根本矛盾:人脑记不住随机长串,而机器很容易暴力破解。通行密钥(Passkey)尝试跳出这个矛盾。
机制简介(原理性介绍)
通行密钥基于 FIDO2 / WebAuthn 标准,核心是非对称加密:
- 你在某网站注册通行密钥时,你的设备(手机、电脑、硬件密钥)在本地安全区生成一对密钥——私钥 + 公钥。
- 私钥永远不离开你的设备,受设备解锁 PIN / 指纹 / 人脸保护;公钥发送给网站保存。
- 登录时,网站发一个随机"挑战值"给你的设备,你的设备用私钥对其签名后返回,网站用公钥验证签名。
- 全过程不传输任何"密码",服务端也没有可供泄露的"密码数据库"——它只存了一堆公钥。
相对密码的优势
- 抗钓鱼:通行密钥在生成时与域名绑定。假站点即使页面长得与真站一模一样,域名不符,设备也不会触发签名——钓鱼网站拿不到任何东西。
- 抗撞库与拖库:服务端只存公钥,即便数据库被攻击者整库拖走,公钥也无法用于伪造登录(它只能"验证",不能"签名")。
- 抗暴力破解:破解非对称签名(如 ECDSA、Ed25519)的难度,远高于破解密码哈希。
- 无需记忆:用设备解锁即可登录,体验比输密码更快。
现实约束(约 2026 年)
- 生态仍在完善:Apple、Google、Microsoft 主流平台均已支持,国内大厂服务(微信、支付宝、银行等)在逐步接入,但覆盖仍不完整。
- 跨设备同步:Apple iCloud 钥匙串、Google 密码管理器、Bitwarden 等已支持通行密钥的云同步,便利性显著提升;代价是把密钥副本放到云端(受云账号本身保护)。
- 兜底方案:启用 passkey 后,仍建议保留密码 + 2FA 作为过渡期兜底,以及妥善保管恢复码。
使用建议:对你最核心的账号(主邮箱、云账号),若服务商已提供 passkey,优先启用;但短期内不要急于删除密码 + 2FA,两者并存一段时间,确保设备丢失时仍有退路。
2. 密码存储的工程原理:哈希、加盐、慢函数
理解服务端如何存你的密码,能帮你理解"为什么同样是拖库,有的后果轻、有的后果重"。
哈希(Hash):单向不可逆
规范的网站绝不明文存你的密码,而是存"哈希值"——用一个哈希函数把密码映射成定长的字符串。哈希是单向的:从哈希值无法直接反推原密码。
历史上常见的哈希函数:MD5、SHA-1(均已不推荐用于密码存储)、SHA-256 等。
但单纯哈希远远不够——因为同一个密码每次哈希结果相同,攻击者可以预先计算出海量常见密码的哈希,做成对照表。
加盐(Salt):让每个用户都不一样
"盐"是服务端为每个用户随机生成的一段字符串,与密码拼接后再做哈希:
存储值 = Hash( password + salt )这样即使两个用户密码相同,因盐不同,存储的哈希值也不同,预先算好的对照表(彩虹表)失去意义。
慢函数(Slow KDF):让暴力破解变贵
即便加了盐,攻击者拿到数据库后仍可用 GPU 高速遍历常见密码。"慢函数"被设计成故意很慢——每次哈希消耗大量 CPU 与内存,把单次尝试成本抬高几个数量级:
- bcrypt:1999 年提出,经典且广泛,可通过"工作因子"调慢。
- argon2:2015 年密码哈希竞赛(PHC)冠军,抗 GPU/ASIC,目前业界推荐首选。
- scrypt:介于上述两者之间。
对普通人的含义
- 你无法控制服务商用什么算法存密码,但可以做一个合理推断:大厂主流服务基本已采用 bcrypt/argon2 类慢函数加盐存储;小站、老系统、自建论坛则可能用 MD5 甚至明文(历史上多次拖库事件证实)。
- 因此一个保守但稳妥的假设是:任何小站的密码都可能以明文形式泄露。这进一步印证了 🟢 基础里的铁律——绝不在小站复用你任何重要账号的密码。
3. 撞库与彩虹表:大规模账号盗用的两条路径
把上面两个机制放回第 3 章的威胁视角下,大规模账号盗用主要走两条路径:
路径一:撞库(Credential Stuffing)
- 机制:攻击者从 A 站拖库(无论 A 站存的是明文还是弱哈希),拿到"邮箱/手机号 + 密码"清单,然后用自动化脚本去 B、C、D……批量尝试登录。
- 成功率:据多家安全厂商报告估算,撞库的"命中率"通常在 0.1%–2% 之间(来源性质:厂商报告,待复核),但攻击是批量的,绝对命中量仍然巨大。
- 你为什么中招:你在多个站用了同一个密码。
- 合法防御:
- 重要账号使用独立密码(见 🟢 基础第 2 条)。
- 开启 2FA——即使密码命中,第二因素仍能挡住绝大多数尝试。
- 关注泄露查询公益服务(Have I Been Pwned 等),一旦发现自己常用邮箱出现在某次泄露中,立即更换相关账号密码。
路径二:彩虹表(Rainbow Table)
- 机制:针对"未加盐或固定盐"的哈希,攻击者预先计算出海量"密码 → 哈希"的对照表(以存储空间换计算时间),拿到目标哈希库后直接反查。
- 有效性条件:只在服务端"不加盐"或"全站统一盐"时奏效。现代规范存储的网站已基本免疫。
- 对普通人的含义:彩虹表主要是历史风险,在今天已不是主流威胁。现在更需要警惕的是撞库和针对个人的钓鱼 / 木马(后者详见第 13、15 章)。
把这两条路径与第 3 章"纵深防御第 2 层(认证)"对应起来:独立密码 → 防撞库;加盐慢哈希 → 服务端职责(你只能用脚投票选靠谱的服务商);2FA / 通行密钥 → 第二层兜底。每一层都在让攻击者付出更高成本,这才是安全的本质。
本章检查清单
读完本章,请逐项自检:
- [ ] 我理解"长度优先于复杂度",重要账号密码均在 12 位以上,且不是生日 / 手机号 / 姓名拼音等可猜内容
- [ ] 我的邮箱、支付、云账号、主用社交账号均使用互不相同的密码
- [ ] 我至少为核心账号(邮箱、支付、云账号)开启了二次验证
- [ ] 我已了解 TOTP 验证器 App 比短信验证码更安全,并已迁移或计划迁移
- [ ] 我已妥善保存每个开启 2FA 账号的备用恢复码(纸质或加密存储)
- [ ] 我已了解密码管理器的作用,并已选型试用或计划试用
- [ ] 我了解通行密钥(passkey)是更安全的认证方向,服务商提供时会优先启用
- [ ] 我理解撞库与彩虹表的区别,并据此调整了自己的密码使用习惯
- [ ] 我知道更换手机 / 重置 2FA 后,要立即生成新恢复码并作废旧码
延伸阅读与参考来源
- 本书第 1 章 隐私与法律框架——本章"可携带权""敏感个人信息"等术语口径源自第 1 章。
- 本书第 3 章 威胁模型入门——本章"五类威胁主体""纵深防御第 2 层(认证)"框架源自第 3 章。
- 本书第 4 章 手机号与账号——手机号作为账号身份的"根",与本章认证体系互为补充;SIM 卡冒补风险直接影响短信 2FA 的可靠性。
- 本书第 13 章(电信诈骗与短信安全)将深入讨论短信劫持机制,解释为什么 TOTP 优于短信验证码。
- Have I Been Pwned(haveibeenpwned.com)——查询自己邮箱是否出现在已知泄露数据集中的公益服务。
- FIDO Alliance / W3C WebAuthn 规范——通行密钥的官方技术标准(fidoalliance.org)。
- OWASP Authentication Cheat Sheet——业界关于认证实现的开源最佳实践(owasp.org)。
⚠️ 本章涉及的厂商名称、产品名为中性列举,不构成商业推荐;具体功能、界面路径可能随版本更新而变化,以服务商官方说明为准。本章数据如未特别注明,均为公开估算,来源性质为厂商报告或第三方聚合,部分待复核。本书内容仅作防御科普,不构成法律建议;部分设置(如启用 2FA、迁移验证器)可能在换机或丢机时影响登录,请读者自行评估并妥善保存恢复码。
⬅ 上一章 第 4 章 手机号与账号 | ➡ 下一章 第 6 章 智能手机权限