如何在不传输明文密码的情况下实现逐用户密码加盐？

1. 服务器端哈希的安全性基础是HTTPS，而非“明文传输不可取” #

你担心前端传明文密码不安全，本质是没意识到HTTPS已经解决了传输过程的加密问题。当启用HTTPS后，前端到后端的所有通信都会被SSL/TLS加密，明文密码在传输链路中是被加密的，第三方无法窃听或篡改。服务器端拿到的密码是解密后的明文，但这一步是安全的——因为只有服务器能解密HTTPS流量。

服务器端用逐用户盐哈希密码，是为了存储安全：一旦数据库泄露，攻击者拿到的是带盐的哈希值，而不是明文密码。逐用户盐的作用是让相同密码的用户哈希结果不同，彻底废掉彩虹表攻击，暴力破解也得针对每个用户单独来，难度指数级上升。

2. 前端加盐是画蛇添足，甚至引入风险 #

前端加盐的思路看似解决明文问题，实则毫无必要，还会带来额外风险：

• 如果用全站统一盐：攻击者只要拿到这个盐，或者拿到任意一个用户的哈希值，就可以把哈希值当作“等效明文”直接用来登录（因为后端会用同样的盐验证），和传明文没区别，反而失去了HTTPS的加密保护优势。
• 如果先获取用户专属盐再哈希：盐本身不需要保密，它就存在数据库里，和哈希值绑定存储。但你想，前端获取盐的请求也是走HTTPS的，那直接传明文密码（同样HTTPS加密）不更简单？而且前端加盐后，服务器还是要再做一次哈希吗？如果不做，那存储的就是前端加盐后的哈希，一旦这个哈希泄露，攻击者照样能直接登录；如果服务器再做一次哈希，那等于多了一层冗余操作，没有提升任何安全性。

3. 逐用户盐的正确用法：盐不需要保密 #

逐用户盐的核心价值不是“保密”，而是“差异化”。正确的流程是：

• 用户注册时：服务器生成随机的专属盐，用盐对明文密码做哈希，把盐 + 哈希值一起存在数据库（比如用冒号分隔）。
• 用户登录时：
  1. 前端通过HTTPS发送用户名和明文密码。
  2. 服务器根据用户名找到对应的盐。
  3. 用盐对收到的明文密码重新哈希。
  4. 对比新哈希和数据库存储的哈希值，一致则认证通过。

哪怕盐被公开，攻击者也无法通过彩虹表批量破解，因为每个用户的盐都不一样，必须针对每个用户的盐+哈希值单独暴力破解，成本极高。

内容的提问来源于stack exchange，提问作者Stryks