登录注册安全实践

你有没有见过这样的设计：注册或登录时，前端从 .env 里拿一个写死的 key，把用户密码拼上这个 key 算个 SHA256，再把哈希值发给后端。后端拿这个哈希值和数据库里存的比对，一致就算登录成功

看起来很聪明——密码没有明文传输，后端也不知道原始密码。但很遗憾，这是一套自己骗自己的安全方案，比直接传明文密码还要危险十倍。今天就借这个问题，把登录注册里的安全逻辑从头掰开聊透

为什么“前端 + 固定 key + 哈希”是灾难

前端没有秘密可言

.env 里的变量只要被 VITE_ 或 REACT_APP_ 前缀引用，最终全都会被打包进浏览器能看到的 JS 文件里。任何人打开开发者工具，搜索一下就能拿到这个所谓的“密钥”。在前端代码里存放的任何固定字符串，都只是字符串，不是密钥

相同密码 = 相同哈希

key 是全局唯一的，SHA256(password + key) 对相同的密码会产出完全相同的哈希值。攻击者一旦拿到数据库，一眼就能看出哪些人用了弱密码，甚至可以提前为这个固定的 key 制作一张彩虹表，把所有弱密码一次性秒破

彩虹表：攻击者提前算好海量常见密码搭配你的固定 key 的哈希值，查表即得原文。后面会详细说

哈希值成了真正的“密码”

后端比对的是 请求里的哈希值 == 数据库里的哈希值。也就是说，这个哈希值本身就是登录凭证。数据库泄露后，攻击者根本不需要还原原始密码，直接用这些哈希值伪造请求就能登录任何账户。

无法更换 key

key 一旦泄露（上线即泄露），你想换 key 就必须让所有用户重新设置密码，否则数据库里存的旧哈希和新 key 算出来的结果对不上。整个系统一炸全炸。

彩虹表与盐

彩虹表是一种用空间换时间的破解工具。攻击者提前生成一个巨大的映射表：常见密码 → 哈希值。拿到你泄露的数据库后，直接查表就行。

如果是这样的情况：
A用户：hash("password" + "随机盐A") → ``abc123...B用户:hash("password" + "随机盐B")→def456...`

那么你在破解的时候，你需要为每个用户的盐值都建立一个彩虹表。盐的作用就体现出来，相同密码不同的哈希值。如果密码足够强、哈希算法又故意很慢，破解单个用户都要花上百万年，攻击就毫无价值了

正确的注册/登录流程

一句话：永远在前端处理好用户界面，把密码明文通过 HTTPS 交给后端，让后端在受信任的环境里做剩下的所有事情。

注册

明文传输account+password，并且在后端生成随机盐值，用随机盐值加密password，一并存于数据库里

登录

明文传输account+password，读取对应account的盐值，加密password后与数据库中数据比对，给前端返回鉴权token即可

有https还要后端干什么

https负责保护传输过程。它在你和服务器之间建立一条加密通道，中间人无法轻易窃听或篡改密码明文。

而后端的慢哈希和盐，负责保护存储过程。