4. 身份认证与授权：密码存储策略（哈希加盐）、多因素认证（MFA）、基于角色的访问控制（RBAC）
身份认证和授权，是软件安全的第一道门。说白了，就是解决两个问题：「你是谁？」和「你能干什么？」。我见过太多项目，功能做得花里胡哨，结果在登录环节就被人捅穿了。这一章，咱们就把这三块硬骨头啃下来。
4.1 密码存储策略：别再存明文了
先聊个老生常谈但总有人踩坑的话题——密码怎么存。我记得刚入行那会儿，接手过一个遗留系统，打开数据库一看，用户密码字段存的居然是明文。我当时后背一凉，连夜给老板写了份整改报告。
4.1.1 哈希 + 盐：标准做法
正确的做法是：哈希 + 盐。哈希是单向函数，把密码变成一串固定长度的乱码。但光哈希不够——如果两个用户密码相同，哈希值也一样，黑客可以用彩虹表反向查出来。所以得加盐。
盐（Salt）是一段随机字符串，每个用户都不一样。存储时，我们把盐和密码拼在一起再哈希。这样，就算两个用户密码相同，哈希值也完全不同。
我个人习惯用 bcrypt，因为它实现简单，社区支持好。下面是一个伪代码示例：
// 注册时
salt = generateRandomSalt(16 bytes)
hash = bcrypt(password + salt)
存储: username | salt | hash
// 登录时
从数据库取出 salt 和 hash
if bcrypt(inputPassword + salt) == hash:
登录成功
else:
登录失败4.1.2 常见哈希算法对比
| 算法 | 安全性 | 速度 | 推荐场景 |
|---|---|---|---|
| MD5 | ❌ 极低（已破解） | 极快 | 不要用 |
| SHA-256 | ⚠️ 中等（无盐时易受彩虹表攻击） | 快 | 仅用于完整性校验 |
| bcrypt | ✅ 高（自带盐，可调成本） | 慢（可控） | 密码存储（推荐） |
| Argon2 | ✅ 最高（抗 GPU/ASIC） | 慢（可控） | 密码存储（新项目首选） |
4.2 多因素认证（MFA）：加把锁
光靠密码，风险太大了。密码可能被钓鱼、被撞库、被社工。所以，我们需要多因素认证（MFA）。它的核心思想是：至少用两种不同类型的证据来证明你是谁。
三种常见的认证因素：
- 知识因素：你知道的东西（密码、PIN码）
- 持有因素：你拥有的东西（手机、硬件令牌）
- 固有因素：你是什么（指纹、人脸）
MFA 就是把这些因素组合起来。比如：密码（知识）+ 手机验证码（持有），或者密码 + 指纹（固有）。
我曾经在一个金融项目中，强制要求所有管理员开启 MFA。结果上线第二天，就有人抱怨「太麻烦了」。但三个月后，我们拦截了一次针对高管账号的钓鱼攻击——对方拿到了密码，但过不了 TOTP 验证。从那以后，再没人抱怨了。
4.3 基于角色的访问控制（RBAC）
认证通过后，就该授权了。RBAC 是目前最主流的授权模型。它的核心是：把权限分配给角色，再把角色分配给用户。这样，你不需要给每个用户单独配权限，管理起来轻松得多。
4.3.1 核心概念
- 用户（User）：系统的操作者
- 角色（Role）：一组权限的集合（如「管理员」、「编辑者」、「访客」）
- 权限（Permission）：对某个资源的操作（如「创建文章」、「删除用户」）
- 会话（Session）：用户激活的角色集合
你想想看，一个电商系统，可能有几十种操作权限。如果每个用户单独配，光配权限就能累死人。用 RBAC，你只需要定义几个角色：
| 角色 | 权限示例 |
|---|---|
| 超级管理员 | 所有权限 |
| 商品管理员 | 创建/编辑/删除商品、查看订单 |
| 客服 | 查看订单、处理退款 |
| 普通用户 | 浏览商品、下单、查看自己的订单 |
然后，把用户丢进对应的角色里就行了。简单、清晰、可审计。
4.3.2 RBAC 的常见坑
4.4 知识结构图：身份认证与授权全景
下面这张图，把本章的核心知识点串起来了。你可以把它当作一个快速参考。
4.5 实践建议：从设计到落地
最后，分享几条我在项目中总结出来的经验：
- 密码策略别太复杂：要求大小写+数字+特殊字符+16位，用户记不住，最后全贴在显示器上。建议用长密码（passphrase）代替复杂密码，比如「我喜欢吃火锅2024」比「P@ssw0rd!」安全得多。
- MFA 要渐进式推广：先让管理员强制开启，再逐步推广到普通用户。别一上来就全员强制，否则客服电话会被打爆。
- RBAC 要定期审计：权限不是配完就完事了。我建议每季度检查一次角色和权限，看看有没有「僵尸角色」或「权限膨胀」。
- 日志记录不能少：谁、在什么时间、通过什么方式、访问了什么资源，这些都要记下来。出了问题，日志就是你的救命稻草。