用户数据（密码）应在客户端还是服务器端加密？安全与实践问询

1. 服务器端加密时，明文密码会被服务器上的恶意脚本拦截吗？服务器被控制后，客户端加密更安全？ #

• 服务器端加密阶段，明文密码在Web服务器接收后、完成哈希加密前，确实会短暂存在于服务器内存中。如果服务器被植入了间谍脚本、后门程序，或者存在恶意运维人员，这段时间的明文密码有被窃取的风险。
• 但如果服务器已经被攻击者完全控制，客户端加密根本起不到真正的保护作用：攻击者可以直接篡改页面上的JS加密代码，让用户输入的明文密码直接被窃取；或者拿到客户端加密后的字符串和对应的加密逻辑，把这个加密串当成“新密码”直接登录系统，反而失去了服务器端加盐哈希的核心安全价值（比如抵御彩虹表攻击、随时迭代加密算法）。

2. 从用户信任角度，客户端加密更有优势？ #

• 这其实是个常见的认知误区。普通用户可能觉得“我的密码没以明文传到服务器”更安全，但实际情况是：
  • 如果网站没配置HTTPS，客户端加密的JS代码本身可能被中间人篡改，反而让用户的密码更危险；
  • 正规网站用服务器端标准哈希算法（比如PHP的password_hash()，自带随机盐），比客户端加密更可靠，因为服务器端可以实现加盐、算法迭代等安全措施，而客户端加密的逻辑是公开的，很容易被破解；
  • 甚至有恶意网站会用“客户端加密”做噱头骗取信任，背地里还是窃取明文密码。
• 所以从真实的信任维度看，客户端加密并不能提升用户的安全感，反而可能掩盖安全漏洞。

3. 知名网站通常选客户端还是服务器端加密？ #

• 几乎所有主流知名网站（比如Google、GitHub、淘宝、Facebook）都采用服务器端加盐哈希加密，不会做客户端加密。原因主要有几点：
  • 服务器端哈希可以使用更安全的算法（如Argon2、bcrypt），并且自带随机盐，能有效抵御彩虹表攻击；
  • 可以随时迭代升级加密算法（比如从bcrypt切换到Argon2），而客户端加密的JS代码是公开的，无法统一更新；
  • HTTPS已经能保障明文密码在传输过程中的安全，不需要客户端加密来弥补传输层的安全问题；
  • 客户端加密会把加密后的字符串变成“等效密码”，一旦数据库泄露，攻击者可以直接用这个字符串登录，反而降低了安全性。

内容的提问来源于stack exchange，提问作者Mattéo Bouliteau