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

赶紧开了吧，早晚得出事儿

早晚得出事儿

我们用 httponly，约束自己不要乱搞 cookie

你是真问还是假问的？
如果真问，你也……

是个狼人

报公司名吧 ，以后绕着走

我已经淡定了。
我还记得某次某个项目问后台，传输过程中账号密码不做个加密吗？答：为什么要加密？
我还记得和同事争论了半天，加密到底有没有用。

现在，我也开始反问，干嘛要加密？
出事？出事的锅大概率不在你身上。
用户？用户在意这些吗？
领导？领导在意这些吗？

逐渐混沌邪恶。

@littleylv 真的想问下，我也不管这块，没事就看了下我司的网站，发现没有公司这样搞的，就很好奇#_#

@lagoon 主要是领导也不知道，就算领导知道也不懂，还不是开发说了算 *-*

@usw 谢谢老哥，回头学习一下

@lagoon #7 传输过程中加密的意义不大。如果开了 https，更加没必要了

有比较大的安全隐患

挺好，将来绝对不用你背锅

那后台存数据库的时候呢，最好也看看。 好像说国家有条例规定不能明文存敏感信息

@lagoon 传输过程中貌似还真的是不需要加密

赶紧跑路

@littleylv 开了 https，不就已经加密了吗？

@lagoon #17 协议加密的我知道，我是说针对密码的字符串单独的加密

@lagoon 一般没什么人做传输过程中加密 或者直接上 https

没毛病

@lp7631010 http 不就是加密吗.....

@littleylv 这不是讨论的不加密的情况吗。。。。

@lp7631010 https 不就是加密吗....

@littleylv 没意义，你加密了密码，别人拿到加密后的密码根本不用解密，照着这个请求发过去你后端还是要认！

@lagoon #22
你这不是杠吗。。。算了你赢

@lagoon 明显你说的不是指 https 好么 你要说包含了 https 那你赢了 你真棒

记得当年考驾照登录过一个网站，用户名和密码都在 url 里

你司肯定有大神坐镇

得出事儿

@lagoon #7 传输过程中对密码字符串本身加密确实没意义，前端的加密都是浮云

@lagoon 不需要加密，加密也没有办法保证安全

不知道为什么要存 cookie。
用 session 不行？我觉得这个锅不是产品就是技术经理的

借楼问一下正确的前端加密方式～

必然不对。如果是我就怼，解决不了就离职。我觉得也不能只是工作，多少也得有点追求有点信念吧。有些事情可以忍，有些事情忍不了。

前端没有安全性可言。。

目测 lz 不是前端，不知道是做那一块的。
如果不熟悉建议让技术负责人定。
不要一上来就标题党

前端是用户的，用户泄密你拦不住，服务端是公司的，公司泄密才是你能管的。前端为什么存密码才是问题，难道除了登录还有什么服务需要密码吗？

我司也是，我说了没用，是说为了实现记住密码功能才这样做的。记住密码功能是这样做的吗

反正我做项目时，用户在前端输入密码时就加盐 hash 一次，传输到后端保存或验证密码时再加盐 hash 一次，不管怎么样，绝对不允许出现用户密码明文在任何环节保留。

前端为什么要操作 cookie，cookie 不是后端写入用来保持 http 请求的用户状态吗？前端传参数不是用 request body 吗？

@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 等，(删掉)而剩余的民科则在研究前端加密(删掉)

原文见: 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

@index90 > hash 不等于加密
没错，你说的对。但是跟我说的有什么关系吗？
我只是在阐述，alw 的做法，是为了让任何环节（键盘记录器、屏幕识别除外）都不泄露出用户的原始密码，我对这种做法表示赞同。

@lagoon 前端不仅要加密, 还要加盐,随机码,防止重放攻击, 麻烦的一比. 且大多是防君子不防小人.
真正想安全, 还是得 HTTPS

不对。
不敢怎么样，token 不是密码，token 可以失效，token 可以在用户异常 ip 变更的时候设置为失效。
密码不能，只要是账号密码正确，哪怕一秒钟换 10 个 ip，也不能设置密码为失效。
所以，暴露密码，绝对不对。

@index90 额，回复完才看到你 55 楼的回复
原来是友军，我还以为你在怼我，非常抱歉……

@laoyur #61 只是表达附议，无意冒犯。

@cp19890714 其实应该把前端理解成一个界面更加友好的“cURL”，接口安全，系统安全都应该是后端的责任。

明文放哪都不对

前端加盐 hash 意义是避免中间人攻击直接获取传输的明文账号和密码，但是无论前端是否加密 账号密码都不能放在 cookie 内的

一般要加密加盐加时间戳

密文防撞库

他该不会是想做“记住用户名和密码”这个功能吧。。。这也太骚了

我司项目上了 https，但还是要求接口入参加密。。。。 请问这有必要吗？

密码在整个系统的流程中只有登陆和重置两种交互用的到...所以问题应该是为嘛要存在 cookie 而不是明文不明文...

无论如何都不能明文存储用户密码。不管在那里。

存密码是傻子，无论是明文还是 hash 甚至加盐后的都不行
为什么不选择 session, 验证有问题直接 revoke 就搞定了

@hirasawayui #72 没有必要，https 已经保证了信道安全。

@Mohanson 信道安全不安全不能一概而论，看是要防止窃听者还是中间人。诸如 DH 这类密钥交换算法，可以在不安全的信道中安全地交换密钥，不过不能防止中间人攻击。

这个还不是最骚的
上个公司 (上市的) 他们活动页面，需要手机号验证码的，直接把验证码明文存 cookie，然后 js 比较 cookie 与用户输入是否一样来校验的。

我想知道什么样的需求要存密码呢？

另外 cookie 存密码做什么？方便 debug ？

从入职到入狱……

也许只是个假的呢

前端路过。。。
前端加密，一般混淆视听，没有多大意义。但实际操作还是会加密。

这位老哥的问题在于： 把明文密码直接存 cookie。
不管出于什么需求，都不能这么做。
且个人意见： 完全看不到这样做的意义。

难道没人怀疑，既然前端直接存明文，后端是不是也用的明文？不然意义何在？

cookie 存明文密码跟桌面搞个 txt 存密码没有任何区别

都需要被吊起来打

是哦，现在 https 了。像以前的 md5 之类的摘要传到后端对比或者创建 session id~~~api 用 key 去混进值里面尾部加所有字符串的 md5 摘要校验真没必要了呢。嘻嘻~~~

对不对？安全原则之一：
加密所有的一切

对用户个人的隐私暴露增加风险, 如果亲戚同事朋友使用电脑看到 cookie 这些信息就把你密码暴露了.
如果密码不是明文的话就还好.

12306 登录接口也是明文

其实没啥大问题，浏览器本身的密码储存的也是明文。

cookie 不是服务端发送的响应报文中的首部字段通知客户端保存的，之后每次请求都带上的么，所以你们用这个要解决什么问题？

跟他说：你好骚

后端把收到的参数都存到 log 里面去了，于是密码明文存在 log 中

登录的时候，是不是前端发送请求时，把密码用时间戳加密一下，后端用前端给的时间戳对称解密，这样是一种解决方案？一来没有明文，二来避免重放攻击，除非加密解密方法泄露了。

@Mohanson 前端在用户输入时对密码做哈希（不是加密！）这个不是密码学问题，而是社会工程学问题。。。
不管什么途径，用户的明文密码流入服务器就是对用户隐私的不负责任。

就是数据库也不能明文储存啊

要不你委婉提醒下好打 MD5 一下也成不是。

@Varobjs 这种我也遇到过，甚至是大公司一个项目的主要登陆页面。直接从 cookie 里读取验证码明文，那费劲吧啦做个验证码不知道有啥意义，可能只能确保用户不走神儿吧

所以 cookie 和 token 有何区别

@alw @laoyur @index90

> 任何环节（键盘记录器、屏幕识别除外）

所以以前游戏盗号用得最多的键盘记录器就让你给除外了？

> 绝对不允许出现用户密码明文在任何环节保留。

最理想的情况是键盘内部加密，敲字符的时候直接通过某种算法进行转换，输入到文本框的直接就是密文，如果你不信任这台电脑的话，明文字符根本不能进到电脑里。

如果你假定这台电脑是不安全不可信的，那么进了电脑以后再加密并不能解决安全问题。
如果你假定这台电脑是安全可信的，那么只需要在离开电脑进入公共网络的时候加密（ SSL ）即可。
在假定安全可信的环境里额外增加安全措施没有什么意义。



除了一种情况。
就是你不信任自己的服务器，怕自己服务器被人黑了会被人拿到用户的原始密码，所以决定不让原始密码进到自己的服务器里。
这种情况我建议咨询网络安全团队……