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

[392039757]

我不是前端，不懂也不敢问 eg: Cookie: userPwd=123456; userName=ws201907

[Mutoo]

抛开传输上的问题来讲。cookies 最大的问题是会被明文存到本地，例如 chrome 是存在未加密的 sqllite 里。
(session cookies 除外)

[codehz]

@nnnToTnnn #137 你用方案一对着 google.com 试试，这就是为啥要有 HSTS 和 HSTS preload
即使用方案二，EV 标记也会被删除）自签名证书无法显示 EV ）

[w99wen]

@fumichael
你想的不对。

[sujin190]

不是据说密码法生效后，网站泄露用户密码是违法的么
楼上说网站没有责任为用户密码加密加盐，保证明文不会泄露窃取，你们是认真的么？谁说没责任了，作死也不能这么作吧

[zckevin]

全站 HTTPS + HSTS
用户禁止 third-party cookies
可破

[msg7086]

@pkoukk 你回错人了吧，我什么时候提到过 Cookie 了？

[fumichael]

@w99wen #143 多多指教

[msg7086]

@nnnToTnnn 对于能执行植入根证书到系统这样的 root 级操作的人，或者能把 HSTS 从系统中剥离的人，请你找出任意一种不需要修改键盘硬件而能保护用户密码的手段。

如果你电脑的 root/最高管理员权限都被拿走了，你还跟我讨论 HTTPS 是否安全？建议先换一把门锁并重装系统，然后再看看这个神通广大的人有没有用伪基站和伪电信服务把你的整个互联网通信给中间人了。

[msg7086]

@fumichael 不需要密码原文的地方永远不应该存储某一种能够还原成密码原文的数据。
也就意味着网站的永久存储层里不应该用到任何「加密」算法，而应该用「散列」算法。

至于每次鉴权时，明文密码在不可信环境（互联网）传输时，使用 SSL 里的非对称的向前保密算法做加密保证可信信道，使用可信渠道（ CA 信任链）保证服务器端可信。这里是需要「加密」的。
这种情况下只有两种泄密可能。一是你电脑环境不可信，比如有木马，或者像上面说的被人往系统 CA 里下了药。再一个是服务器内部不可信，比如服务器被人黑了，替换了组件，把密码提前拦截了。

当明文密码安全到达服务器程序以后，程序就会加盐做散列（散列保证无法还原原文）。过了这一步以后，任何黑客都无法用这个来碰库了。

[hakono]

@msg7086
@codehz
路过说一下， 要绕过 HSTS 并不需要 root 权限，连任何账号都不需要。
HSTS 本身是有漏洞的，在用户第一次访问网站的时候就被劫持了的话，HSTS 是没任何用处的

至于为了填上 HSTS 这个坑出现的 hsts preload list，则是为了填上一个坑又引入的一个坑
要把自己的域名加入 hsts preload list，整个周期走下来至少要十几周时间，差不多 4 个多月，这几个月时间足够让黑客拿到有用的信息了

其次，hsts preload list 的坑还不止这点，为了安全和防止连 hsts preload list 自身都被网络劫持了，浏览器的做法是直接硬编码 hsts preload list 到浏览器里面，意味着你花了几个月时间让自己域名进了 hsts preload list，用户不更新浏览器依旧没用。
试问，有哪个公司能保证上自己网站的用户永远使用最新版的浏览器。 最终，解决这个安全问题的方法就是将安全维护再一次交回了开发公司和用户手上。

[codehz]

@hakono #150 所以我加上了 HSTS Preload(其实你只要用咕咕噜出的新 gTLD，他们自动就会在 preload 列表里，比如.new .app
为啥先说 HSTS 呢，因为没有 HSTS 就没有 Preload(

[msg7086]

@hakono HTTPS 的安全措施是靠多方面努力的，是多方面合作产生的效果。
一定要说的话，如果把用户的网线直接拔了，接进专有网络里，什么都给你劫持干净了，又不给 HSTS Preload，又不让用新版的浏览器，那当然什么都没有用了。

另外，HSTS 对抗的是用户指明要求用 HTTP （即不输入 HTTPS://）的情况。在要求安全性的环境下，直接要求用户把完整的地址和协议输入进去，就不会产生这样的问题。

换句话说，这不是 HTTPS 的错，这是用户没有使用 HTTPS 的错。在危险环境下使用 HTTP，和打网址打错域名其实是类似的结果，只不过前者多一步劫持而已。如果某网上银行的地址是 「 https://bank 」 ，那么你输入「 bank 」或者 「 http://bank 」 就和输入 http://xxyyzz 一样危险。（所以这要么是网站没说清楚的锅，要么是用户没敲对的锅了。）

[l4ever]

你这算什么,我们公司的 api 直接 get 请求的用户名和密码, 牛的一皮. 还不是 http

[todd7zhang]

前端加密的比喻就是

在家里大门 敞开( http) 的情况下, 是否还有必要将小房间的门锁(前端加密)上。
当然了小房间的门锁钥匙，有的就放在小房间门口(一眼就看到)，有的放在茶几下面(混淆 js)

所以，我觉得还是老老实实的关上大门吧 https

[miniwade514]

为什么要存密码呢？密码最安全的存储方式是用户的脑子🧠，要么就是以用户自己选择存到别的地方。写到 cookie 里面是无谓增加风险。

[no1xsyzy]

@cheeto 所有用户数据在客户端加解密，服务器不存储任何形式的密码（连加盐版本也不存储），参考 Mega、Lastpass、ProtonMail 等，但相应的有如下弊端：
1、密码忘记不能找回账号内数据。你可以找回账号，但找回的只会是一个空账号，因为里面的数据只能靠之前的密码解密；唯一的解救手段是提供一个 Key 文件可以解密内容，但无法得到原密码，所以可以用 Key 文件找回之前的数据，但这一过程会清楚账号数据，所以拿到 Key 去拿别人账号必然被发现。
2、不符合中华人民共和国反恐怖主义法的需要。

[hakono]

@msg7086
你这就是抬杠了。我谈的是 HSTS 的问题，你跟我谈安全管理策略的问题。我们说的都不是同一件事，没看到我最后说的吗：
“ 最终，解决这个安全问题的方法就是将安全维护再一次交回了开发公司和用户手上。” 这就是你谈的这些内容。

顺便，你有点搞错论题了，我只是路过吐槽你这一句话
“对于能执行植入根证书到系统这样的 root 级操作的人，或者能把 HSTS 从系统中剥离的人，请你找出任意一种不需要修改键盘硬件而能保护用户密码的手段。”

要从 HSTS 方面下手，根本不需要把 HSTS 从系统中剥离，也根本不需要入侵到对方系统中，我吐槽的是这点

[no1xsyzy]

@mrdemonson 数据库加密并不能防运维和开发，Facebook 前车之鉴，会把明文密码打 log

[hakono]

@codehz 你估计只看到了我回复的一半内容……HSTS Preload 也有坑

[codehz]

@hakono #159 你也没看我括号的内容） gTLD 在 preload list 里的情况下，所有用这个 tld 的都能自动获得 hsts 加成，并不需要 4 个月的问题）