密码认证基础：从策略到传输的全链路安全
密码认证，听起来好像是个老生常谈的话题。但说实话，我在安全领域摸爬滚打这么多年，见过太多系统在「密码」这个看似简单的环节上栽跟头。你想想看，一个系统的第一道防线如果都是纸糊的，那后面再牛的安全架构也白搭。
今天我们就来聊聊密码认证的三个核心环节：策略设计、存储安全、传输安全。这三者缺一不可，就像一条链子，哪一环断了都不行。
核心观点：密码安全不是单一技术点，而是策略 + 存储 + 传输的立体防御体系。任何一个环节的薄弱，都会导致整体安全失效。
一、密码策略设计：别让用户自己坑自己
很多人觉得密码策略就是「长度不少于8位，包含大小写字母和特殊字符」。嗯，这没错，但远远不够。我见过一个项目，密码策略写得天花乱坠，结果用户全把密码贴在显示器上——因为根本记不住。
好的密码策略，要在安全性和可用性之间找到平衡。我个人习惯从以下几个维度来设计：
| 策略维度 | 推荐做法 | 避坑要点 |
|---|---|---|
| 最小长度 | 至少 12 位 | 8 位在现代算力下已经不够安全 |
| 字符组合 | 至少 3 种字符类型 | 不要强制要求所有类型，否则用户会写「P@ssw0rd!」 |
| 密码过期 | 90-180 天 | 太频繁会导致用户用「Password1!」「Password2!」这种模式 |
| 历史密码 | 禁止使用最近 5 次 | 太多历史记录反而增加用户记忆负担 |
| 常见密码黑名单 | 必须启用 | 「123456」「password」这种必须拦截 |
我的经验：曾经有个客户坚持要用「每 30 天强制改密」的策略。结果呢？用户把密码写在便签纸上贴在工位隔板上。后来我们改成 90 天 + 黑名单 + 双因素认证，安全水平反而提升了。有时候，过度限制就是最大的安全隐患。
二、密码存储安全：哈希加盐不是选择题
这是我最想强调的部分。你猜怎么着？2024 年还有公司在数据库里存明文密码。每次看到这种案例，我都想顺着网线过去摇醒他们的架构师。
密码存储的核心原则就一条：永远不要存储密码本身，只存储密码的哈希值。但哈希也不是随便找个算法就行的。
2.1 为什么不能直接用 MD5/SHA-1？
MD5 和 SHA-1 是快速哈希算法。快速意味着什么？意味着攻击者每秒可以计算几亿次。配合彩虹表，一个 8 位纯数字密码几秒钟就能被还原。
正确的做法是使用慢速哈希算法，比如 bcrypt、scrypt、Argon2。这些算法故意设计得很慢，让暴力破解的成本变得不可接受。
2.2 加盐：每个密码都要有自己的「身份证」
加盐就是在哈希之前，给每个密码拼接一段随机字符串。这样即使两个用户设置了相同的密码，存储的哈希值也不一样。
我曾经在代码审查时发现一个项目，所有用户都用同一个盐。这跟没加盐有什么区别？攻击者只要破解一次，所有相同密码的用户就全暴露了。
// 正确的加盐哈希示例（Node.js + bcrypt）
const bcrypt = require('bcrypt');
// 注册时：生成盐并哈希
const saltRounds = 12; // 工作因子，推荐 10-12
const hashedPassword = await bcrypt.hash(password, saltRounds);
// 存储 hashedPassword 到数据库
// 登录时：验证密码
const isValid = await bcrypt.compare(inputPassword, storedHash);
// 返回 true/false⚠️ 重要提醒：盐必须满足以下条件：
- 每个用户独立生成（至少 16 字节随机数）
- 与哈希值一起存储（不需要保密）
- 永不重复使用
我曾经见过一个系统，盐是用用户名的 MD5 生成的。这等于没加盐，因为攻击者可以自己算出来。
2.3 哈希算法对比
| 算法 | 推荐度 | 特点 | 适用场景 |
|---|---|---|---|
| bcrypt | ⭐⭐⭐⭐⭐ | 成熟稳定，广泛支持 | 大多数 Web 应用 |
| Argon2 | ⭐⭐⭐⭐⭐ | 2015 年密码哈希竞赛冠军 | 新系统首选 |
| scrypt | ⭐⭐⭐⭐ | 内存硬，抗 GPU 攻击 | 对硬件攻击敏感的场景 |
| PBKDF2 | ⭐⭐⭐ | FIPS 认证，但抗 GPU 能力弱 | 合规要求严格的场景 |
| MD5/SHA-1 | ❌ 禁止使用 | 极快，彩虹表可秒破 | 仅用于校验完整性，绝不用于密码 |
三、密码传输安全：HTTPS/TLS 是底线
好，现在你的密码策略很完善，存储也很安全。但如果传输过程中被截获了呢？我见过一个真实案例：某公司的 API 在登录时用的是 HTTP，结果内网有人抓包，管理员密码直接暴露。嗯，那场面，相当尴尬。
HTTPS 不是可选项，是强制要求。而且不是只对登录页面启用，整个站点都应该用 HTTPS。
3.1 TLS 的核心作用
- 加密传输：防止中间人窃听密码内容
- 身份验证：确保你连接的是真正的服务器，不是钓鱼站点
- 完整性校验：防止数据在传输过程中被篡改
3.2 常见误区
很多人觉得「我用了 HTTPS 就万事大吉了」。其实不然。我总结几个常见的坑：
- 混合内容：页面是 HTTPS，但引用了 HTTP 的图片或脚本。攻击者可以通过篡改脚本窃取密码。
- 弱 TLS 版本：还在用 TLS 1.0/1.1？赶紧升级到 TLS 1.2 或 1.3。
- 证书问题：自签名证书、过期证书、域名不匹配的证书，都会让用户暴露在风险中。
- HSTS 缺失：没有 HSTS 头，用户第一次访问时可能被降级到 HTTP。
我的建议：在 Nginx 或反向代理层强制 HTTPS 重定向，并配置 HSTS。这样即使用户手抖输入了 http://，也会被自动跳转到 https://。另外，别忘了在安全响应头里加上 Strict-Transport-Security。
3.3 传输安全的额外措施
光有 HTTPS 还不够。我习惯在应用层再加一道防护：
- 登录接口限流：防止暴力破解，同一 IP 或同一账号的失败尝试次数要有限制
- CSRF Token：防止跨站请求伪造，确保登录请求来自你的页面
- 前端加密（可选）：在 HTTPS 基础上，对密码做一次前端哈希。虽然 HTTPS 已经加密了传输，但多一层防护总没坏处
// 前端密码哈希示例（配合 HTTPS 使用）
async function hashPassword(password) {
const encoder = new TextEncoder();
const data = encoder.encode(password);
const hashBuffer = await crypto.subtle.digest('SHA-256', data);
const hashArray = Array.from(new Uint8Array(hashBuffer));
return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}
// 注意：前端哈希不能替代后端哈希！
// 后端仍然需要用 bcrypt/Argon2 做慢哈希⚠️ 再次强调：前端哈希只是传输层的补充，不能替代后端的慢哈希。因为前端哈希后的值，在后端看来就是「明文密码」。如果攻击者拿到了这个哈希值，可以直接用它登录。
小结
密码认证的安全，说白了就是三个字：全链路。策略上让用户设置强密码，存储上用慢哈希加盐保护，传输上用 HTTPS 加密。这三者就像三根柱子，少一根整个房子都会塌。
我记得有一次给一个金融客户做安全审计，发现他们的密码策略、存储、传输都有问题。我们花了三个月全部整改，后来他们通过了等保三级认证。说实话，看到客户从「漏洞百出」到「合规达标」，那种成就感还是很强的。