2、身份认证基础：身份标识与凭证、单因素认证、双因素认证、多因素认证
聊到身份认证，我经常跟团队里的新人说一句话：认证的本质，就是回答三个问题——「你是谁？」「你凭什么证明？」「我信不信？」。
听起来简单吧？但就是这三个问题，在真实世界里折腾出了无数种方案。今天这一章，咱们就把地基打牢。
2.1 身份标识与凭证：一对不能分开的兄弟
先搞清楚两个概念：身份标识（Identity） 和 凭证（Credential）。
身份标识，就是那个唯一的「名字」。比如你的用户名、邮箱、工号、身份证号。它只负责告诉系统「我是谁」，不负责证明。
凭证，才是用来证明「你确实是那个人」的东西。比如密码、指纹、短信验证码、硬件 Key。
核心原则：标识可以公开，凭证必须保密。我在一次安全审计中见过某系统把用户名的 MD5 当凭证用——这其实只是换了个马甲，标识还是标识，根本起不到凭证的作用。
举个例子：
- 用户名 → 标识（公开）
- 密码 → 凭证（保密）
- 身份证号 → 标识（半公开）
- 身份证本身 → 凭证（物理持有）
你想想看，如果标识和凭证混为一谈，会出什么问题？
我见过一个内部系统，直接用员工工号作为登录密码的初始值。结果呢？工号是公开的，等于人人都有钥匙。这种设计，说白了就是给攻击者送人头。
2.2 单因素认证：最常用，也最脆弱
单因素认证，就是只靠一种凭证来验证身份。
最常见的例子：密码登录。你输入用户名和密码，系统核对一下，通过了就放行。
单因素的「因素」通常分三类：
| 因素类型 | 含义 | 常见例子 |
|---|---|---|
| 知识因素 | 你知道的东西 | 密码、PIN码、密保答案 |
| 持有因素 | 你拥有的东西 | 手机、硬件 Token、智能卡 |
| 固有因素 | 你本身的特点 | 指纹、人脸、虹膜 |
单因素认证的问题很明显：只要这一个因素被攻破，防线就全垮了。
我曾经参与过一个金融 App 的渗透测试。他们的登录只有「手机号 + 短信验证码」。短信验证码属于持有因素（手机），但问题是——如果用户手机丢了，或者被 SIM 卡劫持了，攻击者就能直接登录。这就是单因素的致命伤。
避坑指南：不要以为「密码 + 验证码」就是双因素。如果验证码发到同一台手机上，它本质上还是「持有因素」的变种。真正的多因素，必须来自不同类别的凭证。
2.3 双因素认证：多一层，安全翻倍
双因素认证（2FA），要求用户提供两种不同类别的凭证。
最常见的组合：密码（知识因素）+ 手机验证码（持有因素）。
为什么双因素比单因素安全得多？
- 攻击者要同时攻破两个不同维度的防线
- 密码可能被钓鱼，但手机在你手里
- 手机可能被劫持，但密码你不知道
我个人的习惯是：所有涉及资金、隐私、管理权限的系统，必须开启双因素认证。哪怕只是个人 GitHub 账号，我也绑了 TOTP（基于时间的一次性密码）。
双因素的常见实现方式：
| 方式 | 因素组合 | 典型场景 |
|---|---|---|
| 密码 + 短信验证码 | 知识 + 持有 | 银行转账、网站登录 |
| 密码 + TOTP（如 Google Authenticator） | 知识 + 持有 | GitHub、AWS 管理控制台 |
| 密码 + 硬件 Key（如 YubiKey） | 知识 + 持有 | 企业内部系统、高安全环境 |
| 指纹 + 密码 | 固有 + 知识 | 手机解锁、支付确认 |
小技巧：如果条件允许，优先选择 TOTP 或硬件 Key，而不是短信验证码。短信有被拦截、SIM 卡劫持的风险。我曾经在项目中遇到过攻击者通过运营商客服重置 SIM 卡，然后拦截验证码的案例——嗯，那之后我对短信 2FA 就多了一份警惕。
2.4 多因素认证：层层设防，步步为营
多因素认证（MFA），就是使用两种或以上不同类别的凭证。其实双因素已经是多因素的一种特例。但在实际工程中，我们通常把「三种及以上」才叫多因素。
典型的 MFA 流程：
- 第一步：输入用户名和密码（知识因素）
- 第二步：输入 TOTP 验证码（持有因素）
- 第三步：指纹或人脸识别（固有因素）
为什么要搞这么复杂？
你想想看，如果攻击者拿到了你的密码，他还要拿到你的手机；就算他拿到了手机，还得破解你的指纹。三道关卡，每一道都增加攻击成本。
我在设计银行核心系统的认证方案时，就采用了三因素：
- 柜员登录：密码 + 智能卡 + 指纹
- 大额交易授权：密码 + 硬件 Token + 人脸识别
说实话，多因素认证也有代价——用户体验会下降。每次登录都要掏出手机、按指纹、输密码，确实烦。所以实际工程中，我们通常根据风险等级动态调整：
- 查看普通信息：单因素（密码）就够了
- 修改敏感设置：提升到双因素
- 转账、提权操作：必须三因素
工程原则：安全性和易用性永远是 trade-off。我的做法是：默认用双因素，高风险操作升到三因素，低风险场景允许单因素降级。别一刀切，也别放任不管。
2.5 知识体系总览
下面这张图，把这一章的核心逻辑串起来了。我建议你多看两眼，理解因素之间的层级关系。
2.6 工程中的选择建议
说了这么多理论，最后给点实在的建议。我在实际项目中，通常这样选型：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 个人博客 / 低风险应用 | 单因素（密码） | 够用，别过度设计 |
| 企业邮箱 / 内部系统 | 双因素（密码 + TOTP） | 平衡安全与体验 |
| 金融交易 / 管理后台 | 多因素（密码 + 硬件 Key + 生物识别） | 安全优先，容忍一定复杂度 |
| 移动端支付 | 双因素（生物识别 + 支付密码） | 用户体验好，安全达标 |
我的经验：别一上来就上三因素。先做单因素，然后根据安全审计结果逐步加固。我曾经见过一个创业团队，产品还没上线就搞了三因素认证，结果用户流失率飙升——说白了，安全是手段，不是目的。
好了，这一章的内容就到这里。身份标识与凭证是认证的基石，单因素、双因素、多因素层层递进。理解清楚这些概念，后面讲认证协议、OAuth、SAML 的时候，你才能知道它们到底在解决什么问题。