这是我写下服务端密码安全专栏的第一篇，也是想敲响的一个警钟：密码，不只是登录的钥匙，更可能是一次数据泄露的开关。
不夸张地说，每一个不安全的密码实现，都是一次"待触发的事故现场"。而这些事故，从未停过。
🧨 密码泄露，从未遥远
或许还记得，LinkedIn 曾因密码存储未加盐而导致 1.1 亿用户密码泄露。攻击者轻松利用"彩虹表"反查出明文。
当然，如果觉得上面的例子比较老旧，没有很强的说服力，你也可以在这里看到今年更多的密码泄露的新闻2025年重大数据泄露事件汇总。
问题不是"密码被破解"，而是"密码根本没被好好保护"。
😅 开发者最常犯的几个错
下面这些"经典错误"，可能你也见过、甚至写过：
❌ 明文存储
go
password := r.FormValue("password")
db.Exec("INSERT INTO users (password) VALUES (?)", password) // 最初接触后端开发的我是这样的（这在数据库层面相当于裸奔------只要有人能查库，就能看到全部用户密码。
❌ 弱哈希算法
用 MD5(password) 存密码，看似加密，实际上在攻击者眼里只是"熟练操作"：
- 入门开发者通常不设置盐(虽然MD5也可以使用盐)，容易被彩虹表秒破
- 算法快，暴力破解成本低
❌ 加错了盐（Salt）
即使用了 bcrypt，但若所有密码都用同一个盐，那就是"安全的幻觉"。正确做法是：为每个密码生成独立的随机盐。
🤔 前端加密 ≠ 安全
很多初学者会问：
我前端加密过了呀，AES、Base64 都用了，还不安全吗？
答案是：加密≠安全，安全是系统性防御。
前端加密只是让数据在传输时"看起来安全"，但如果服务端仍然存明文，那加密只是个花瓶：
- 前端加密密钥（常有的事情，毕竟F12就看到了）一旦泄露，所有密码裸奔
- 加密内容如果直接存，攻击者照样可以离线解密
服务端需要独立负责对密码的安全存储：合理的哈希算法、动态盐值、强策略校验、重置机制、审计与防爆破。
🧭 这个专栏要解决什么？
我希望通过这个专栏，和你一起系统梳理服务端密码管理的各个方面：
-
密码的本质与误解，先打好基础，扫除认知盲区。
-
哈希算法选择和盐的使用，深入技术细节，解决"核心痛点"。
-
密码校验与攻击面，从安全攻防角度提升认知，避免漏洞。
-
密码重置机制，处理实战中常被忽视的安全环节。
-
密码强度策略，兼顾安全与用户体验，落地应用。
你将看到的不只是代码，而是背后的安全理念 与工程权衡。
🧠 安全，是系统性的工程，不是"那一行代码"
密码管理不是一个函数的问题，而是一整套机制的设计。
你写的服务，承载的不只是技术逻辑，还有用户的信任与隐私。如果一行 md5(password) 就能让系统崩塌，那么修补的就不是代码，而是你的信誉。
所以，不要"写一个登录接口"这么简单地想问题。请你带着对风险的敬畏，一起来构建属于现代服务端的密码安全体系。
下一篇，我们将从最基本也最被误解的一个概念讲起：密码的本质与误解？