我司前端把密码明文扔到 cookie 里面，这样做对吗

@YUyu101 对啊，前端为啥要存密码？

@alw #39 那么我问你，“用户在前端输入密码时就加盐 hash 一次”，这个盐，你是不是写在 js 了，那别人不就知道了？所以跟没加密不是一样？
后端加密的好处就是别人根本不知道你的盐

是个狼灭

@alw #39 后端保存的密码是可逆加密吗?

加密其实都是针对特定人加密的，
https 是防网络中间人，
数据库密码加密是放黑客、防运维、防开发，
前段密码加密无实际意义，但也绝不能把密码放 cookie 里面

这个做法问题不大。cookie 中放<token>和放<明文密码>，大多数时候唯一的区别就是取消一个设备对账号的访问权必须修改密码，而采用 access-token 就只用废除 token 即可。其他的关于加密、窃取方面的行为都是没区别的。

即使要甩锅，也是后端的锅：不应该提供 cookie 中明文密码认证的途径。管前端吊事。

微软 asp .net core web 框架的做法是：cookie 附带一个 claim 和 security-token。claim 就是服务器签发的用户名的证明，好像是带签名（ username+signature ）的，密钥存在哪里我没有深究。security-token 每改一次密码或者重新绑定一次电话号码等都会变一下，这样就可以实现账号安全信息变更时自动废除之前的访问权，并且不用向用户呈现“token”或者设备的概念，只需修改密码或者电话号码就一切安全，比较符合自然的逻辑。

记住密码这个机制应该是浏览器控制的，用户可控。对 Web 应用而言记住登录状态不应该是记住用户口令与密码明文，而是一个凭证，也就是 token 或者别的什么。

但是这个凭证确实不用加密。

@lagoon 开 https 传输中就没必要加密了。
不开 http，加密也没大意义。

我猜锅是后端的，前端也只是被逼无奈

这是个严重的安全隐患

@lagoon

复制一段以前我发过的话:


最近正好接触密码学，简单和回答一下：在信道安全的假设下，对通信数据做加密是没有意义的。比如你登录远程 linux 服务器，你是直接输入明文密码的。而在信道不安全的情况下，对通信数据加密有意义又没有意义：因为你必须把密钥通过信道传送给对方。

所以世界上正经的计算机科学家都在解决信道安全问题： https, ssl, tls 等，(删掉)而剩余的民科则在研究前端加密(删掉)

原文见: https://tanronggui.xyz/t/608692#r_8018696

@littleylv > 这个盐，你是不是写在 js 了，那别人不就知道了？
注意他说的 hash 一词，别人能知道你的前端处理逻辑，也能拦截到 hash 后的值，但没法知道用户输入的原文啊

嗯 我想了想 既然是前端背锅 那么一定是输入密码的时候 js 记录 那么一定是没有 httponly 的 且不说日志里面是不是可能存了一大堆这种数据 一旦界面有 xss 之类的 就可以获取账号密码了 都不用做持久化

这里对话上面的程序员们 有些人觉得 上个 https 防中间人就好了 你们知道有种东西叫做隐患 此外密码和 session 不同 密码是长期的 甚至可能多网站通用 以及可能包含用户信息

@laoyur #52 没必要用原文啊， 直接模拟请求发送 hash 之后的值给服务端， 服务端无法区分的

cookie 放敏感信息（密码，密文，token，key ），其实都没有问题，问题是明文。
这里的明文是指用户所输入的字符串信息，原封不动地存储在 cookie 中，那么即有可能被泄露。

正确的做法是，前端存储加盐哈希后的密码，这样文本存储在 cookie 中是没有问题的。这里就需要后端登录接口，所接受的密码字段，是哈希后的密码。所以这里后端可能也要背锅。

补充：
LZ 所提的问题不是传输安全问题，不需要在中间人挟持或密码传输安全等问题上讨论。这些问题的答案我觉得#51 说得很好。
这里的问题，应该是客户端信息安全问题。

@lihongjie0209 你没看懂 @alw 哥的意思，他这么做是为了 [保护用户密码明文] ，不是说为了防止传输过程中被截取（传的是 hash，截取了也泄露不了密码明文）

@laoyur hash 不等于加密，实在太多人分不清了，哎

前端加密意义是什么？代码都功能开的的，谈什么加密

@lagoon 加密肯定会更安全些, 但是既然加密了, 干嘛不直接用 HTTPS