客户端与服务端双重密码哈希方案可行性验证

你的双重哈希方案是否可行？ #

这个方案可行但意义有限，甚至可能埋下安全隐患。
客户端先做无盐无pepper的哈希，本质只是把明文密码转换成了另一个固定字符串——同一个明文密码每次哈希结果完全一致，比如"123456"会固定变成某个哈希值。黑客拿到这个哈希值，照样能用彩虹表反查出原密码，和直接传明文的风险没本质区别。如果客户端用的还是MD5这种弱哈希算法，反而会直接拉低整体安全等级。

常规做法是什么？ #

• 先把HTTPS配置到位：HTTPS被破解的概率极低，只要用TLS 1.2及以上版本、强加密套件、定期更新证书，明文密码在传输过程中是安全的。没必要为了极小的HTTPS风险，做客户端哈希这种画蛇添足的操作。
• 服务端加盐哈希的标准流程：
  1. 用户注册时，服务端生成随机唯一的salt（长度至少16字节，越随机越好）。
  2. 服务端将明文密码与salt组合（推荐用HMAC算法，比简单拼接更安全），再用bcrypt、Argon2或者PBKDF2这类高强度、慢哈希算法进行多次迭代哈希。
  3. 把salt和最终的哈希值一起存到数据库；pepper作为全局密钥，要么在哈希前和密码+salt组合，要么作为HMAC的密钥——pepper必须存在服务端的环境变量或密钥管理服务里，绝对不能和哈希值、salt一起存数据库。
• 为什么不搞客户端哈希：客户端拿不到存在数据库里的salt，只能做无盐哈希，生成的哈希值是固定的，反而更容易被彩虹表破解；而且前端哈希算法如果实现有问题（比如用了弱算法、代码被篡改），会直接把密码暴露在风险里。

关于salt和pepper的正确用法 #

• salt是每个用户专属的，作用是破解彩虹表攻击，必须随机唯一，不能重复使用。
• pepper是服务端全局的额外密钥，就算数据库被泄露，黑客没有pepper也没法破解哈希值，进一步提升安全性。

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