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

[392039757]

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

[Allianzcortex]

很多用户多个网站会用同一个密码，加盐 /加盐可以保证就算是这个密码在传输过程泄露了，用户的其他网站账户也相对安全。当然网站没有责任做这个

[Pastsong]

@msg7086 自己服务器本来就不该存原始密码，只存加盐的 hash

[Pastsong]

@Allianzcortex HTTPS 就是来保证密码在传输过程不会泄露的，明文没有问题

[Allianzcortex]

@Pastsong 嗯，就是前面说的信道问题，往好处想预防类似以前的 12306 这样的自签证书？ belt & suspender

[Allianzcortex]

@Pastsong 服务器存密码明文的前车之鉴就是 CSDN

[laoyur]

@msg7086 照你的理论，反正键盘记录器防不了，就啥安全措施都不用做了，别挣扎了，都明文好了，是这个意思吧？

[darknoll]

用 httponly 还有 https，没什么卵事

[realpg]

@darknoll #107
上别人电脑直接 F12 就看见明文密码了……

[alw]

@msg7086 这是大佬
我没想那么多，就是一把梭，hash 就完事了。

[sevenzhou1218]

我司也是啊，至少我们组的是，还好做的是公司内部项目，单点都是明文传输。

[KuroNekoFan]

不对

[OnlyShimmer]

其实在 cookie 放账号密码没什么问题,我个人猜测一下应该是要做记住账号密码 (我做过...)我一般都是 Bash64 转换一下再把敏感字换换( userPwd,userName)之类,这种东西真的是防君子不防小人,能黑你的人那肯定是知道这些,只能防防那些只知道按 F12 的人啦,心理安慰大于实际应用,再说因为有这一功能(记住账号密码)其实在密码输入框改一下 type 就能看到明文密码(本人健忘,经常这样干),如果不是记住账号密码这一功能,就当我放了个屁......

[NerverLibis]

@lagoon 中间人攻击

[NerverLibis]

@mrdemonson 2028 位以上 dh 公钥才有点用，要不然几分钟就给破了

[msg7086]

@laoyur 是的，我们这里连银行的网银都是这么操作的，密码明文直接送进 SSL 安全层。

[msg7086]

@Pastsong 说的不是永久存储，是说内存变量。

[zdnyp]

https 也不是特别安全啊，看网络环境。没遇到过中间人攻击吗？如果是加密的，被截取到后端也认，那这个 cookie 也是有时限的，但是明文的，被截取到就任人宰割了。

[beastk]

前端还是有必要加密密码等数据的，你们怕是没被撞库过。还民科，怕是没吃过亏吧。

[annielong]

那百度的 BDUSS 不也是本地存，F12 复制出去就能用

[akakidz]

后端不加密前端不都是多余的操作吗...顺便借楼问一下正确的前端加密方式～

[encro]

1，cookie 会随着 http 请求头每次发送到服务器端，所以设置过多的 cookie 无形增加了传输带宽；
2，cookie 可以被客户端修改，明文存储容易被黑客修改后进入其他账户，比如将用户名或角色修改为 admin，从而拥有管理身份；
3，在传输过程中被拦截，因为各个地方接入服务商都是不干净的，现在 HTTP 网站被地方电信机房挂码概率为总体 20%以上，首次 80%以上，对方要拿密码是轻而易举的。

[liuzhiyong]

当然不对啦。

[xuanbg]

这种做法绝对是已经违法了。等保 2.0 了解一下

[killerv]

我见过一个事业单位的网站，有个记住密码功能，做法就是密码扔 cookie 里……

[skylancer]

@zdnyp cert pinning 了解一下

[xiaokui]

这不扯么？赶紧修改吧

[akakidz]

看了一下回复才明白楼主的意思，前端这样搞肯定是不行的:)

[qinxi]

我见过 社交软件 用户列表返回值带明文密码的...

好在这家公司倒闭了

[chennqqi]

首先不合规。
其次不安全，楼上的这些兄弟不要混淆 https 和加密。https 解决的是传输信道的安全，不是解决密码验证逻辑的安全。
还有楼上说的窃取 cookie 也可以获得登录权限的这种，窃取 cookie 和窃取密码是两种情况。你把密码存放到 cookie 里，别人拿了密码在哪儿登录都可以。你没有存放密码，别人窃取了 cookie，在 cookie 失效时就不能登录。另外如果服务端做了 cookie 客户端验证。也可以做到 cookie 其他地方登录无效的。

[chennqqi]

补充一下：说网站没有责任做这部分密码安全的请仔细读一下《网络安全法》，网络安全法实施后，这些是网站经营者的责任，由于网站经营者的责任导致用户损失的要承担法律责任

[laoyur]

@killerv 你说的那个站，可能是 @13725151469wy 哥做的

[component]

安全感是自己给的，小伙子。

[keepeye]

有的客户就是要求记住用户名+密码，下次不用手动输入，不是要记住登录状态，请问各位大牛前端该怎么实现才绝对安全？

[hakono]

@keepeye lastpass 解君愁

[Yvette]

@keepeye 不是前端不了解，不过至少所有我用过的国内国外的网站，没有任何一个是可以选择记住密码的，都是只有记住用户名或者登陆状态

[pkoukk]

@msg7086
很多用户的账号密码是多网站通用的，不做任何处理记录在 cookie 里，有着明显的隐私泄露问题
上厕所的时候隔壁小哥看一眼你的电脑，就把你的账号密码抄走了，没问题么？
确实对于前端来说，如果操作系统环境不受信任，任何加密都是无意义的。
但是又不是所有安全问题都出在操作系统层面上

[nnnToTnnn]

@Pastsong 举个攻击 HTTPS 的例子。

A 客户端 用的 Google 浏览器 - 网址: xxx.com IP 1.1.1.1

C 中间人 IP: 2.2.2.2

攻击方案一

------ 1. 拦截用户的 dns 请求，将 xxx.com 请求跳转到 xxx.cn
------ 2. 将 xxx.com 降级为 http
------ 3. xxx.cn 用正常的证书进行签发，然后代理 xxx.com 的 http 请求
------ 4. 用户访问 xxx.com ，即可获取解密出来的所有数据

攻击方案二

----- 1. 在 A 客户端中植入根证书
----- 2. xxx.com 解析到 2.2.2.2 ,反向代理到 xxx.com
----- 3. 用户访问 xxx.com ，即可获取解密出来的所有数据


B 服务端 IP： 1.1.1.1 端口 443



不知道你们为什么会觉得 https = 安全？

[keepeye]

有的客户就是要求记住用户名+密码，下次不用手动输入，不是要记住登录状态，请问各位大牛前端该怎么实现才绝对安全？
@Yvette
@hakono
我们做开发的呢，不要总是我以为，很多时候要面对客户以为，给钱的是大爷😭 当然如果有个靠谱的产品在前面怼客户那也行

[ihciah]

贵司是出 ctf 题的吗

[fumichael]

我觉得加盐加密更多是为了

部分用户不同网站设置密码都是一样的 + A 网站密码泄露的情况下，避免了 BCDEFGH…其他网站被一锅端了

同理，如果你把卡的密码都设置成一样，知道你一张卡的密码就知道了你其他卡的密码

加盐加密就对用户的原始密码保护了，减少了碰库的可能

以上都是我个人的想法，可能也有不对，仅供参考

[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 个月的问题）

[no1xsyzy]

但是其实还要担心一点：现在大部分服务器是运行在 VPS 上的，实际上如果过程中以明文存储在内存上，如果 VPS 提供商扫描内存的话是可以知道密码的。试问在座有几个人会对自己服务器上传入的数据在 HTTP 层面先做随机化分布？（即 SSL/TLS 层解密后在内存位置是打乱的）
Cookie 的另一个问题就是反授权时 token 之流方便一点，存用户名密码就需要重置密码了。

[no1xsyzy]

@l4ever get 不是 http ？没太明白

[l4ever]

@no1xsyzy 按快了, 少了个 s 我就

[l4ever]

@no1xsyzy 你看,又按快了, 少了个 s 我就 ctrl+enter 了.

[w99wen]

@fumichael
对于加密
有两个基本概念：对称加密，非对称加密
对于 hash 之类的，其实是取得摘要，指纹，或者说特征值，不是加解密。
每个固定内容，特征值应该是唯一的。同时我们不能直接从特征值得到原内容，除非你计算过或者说记得这么一个对照表，有这些一一对应关系。
但是这其中有一个问题，大部分需要取摘要的内容都很短，很容易被人们计算出来，并且保存到对照表中（这个表，就叫彩虹表），所以才要加盐，加上一段随机字符，将内容变长，比如扩充到 50 位，那这个 50 位的彩虹表，就已经无法建立了，太大了。
加盐，是为了对抗彩虹表。这个是根本目的。

[w99wen]

@fumichael

加盐之后，攻击者不能从彩虹表获得 md5 之前的原内容。也就是我们的密码。

[aaronhua]

@chennqqi +1。有朋友做安全的，这种明文的是过不了等宝的。

[no1xsyzy]

@fumichael 数据库加盐加密主要是为了防止彩虹表和哈希字典的。
人们早就知道 'E10ADC3949BA59ABBE56E057F20F883E' = md5('123456')
但如果你采用加盐的方法，你看到 'hellomyzebra,yestheyaresocute:' '3A64C835017B142A97B5ADAECF249673' 又怎么知道密码是多少？
没盐的情况下，你可以直接 select * from users where passhash = 'E10ADC3949BA59ABBE56E057F20F883E' 得到这些人密码是 '123456'，甚至给一个哈希字典能够直接 select users.*, hashdict.hashee as password from users left join hashdict on users.passhash=hashdict.hashed 取出所有弱密码，整个耗时不过几秒。
用上彩虹表的话 20 位以下密码也花不了多久。

但加盐首先直接破坏彩虹表，其次弱密码爆破也需要很久，脱裤后有足够久的时间告警所有用户改密码了。

数据库中更标准的是采用 bcrypt 等方式，单密码校验需要 1 秒（可调参使得时间更长），简单 6 位纯数字密码，数据空间达 100 万，就是十几天，还多半不会命中。

[no1xsyzy]

@w99wen 彩虹表不是对照表，而是一个依赖于特定的哈希函数 hash 和随意指定的、反转了定义域和目标域的函数（实质上是另一种 hash，不过通常生成的是变长字符串） rehash 构造的简化对照表，它的结构和 hash 强对应，

彩虹表就算你在 6 位数字上加一位数字的盐，因为哈希算法被改变 new_hash = d=>hash(salt+d)，导致整个彩虹表不可用，但对照表的话刚开始就构造 7 位对照表的话还是可以使用的。
这就是为什么需要每个用户独立生成盐，否则还是可以用彩虹表。

[kiracyan]

明文保存密码都是弱智.不管在哪

[nnnToTnnn]

@codehz
@zckevin
@msg7086

方案一，可能说的不够详细但是 HSTS 是可以绕过的，包括现在的浏览器的硬编码

攻击方案一

------ 1. 拦截用户的 dns 请求，将 google.com 请求跳转到 google.com.hook
------ 2. 将 google.com 降级为 http(正常请求获取到 google.com 的数据)
------ 3. google.com.hook 用正常的证书进行签发，然后代理 google.com （步骤二的数据）的 https 请求
------ 4. 用户访问 google.com.hook，即可获取解密出来的所有数据


和原始访问的差距是

之前访问的是 google.com

拦截后访问的是 google.com.hook


talk is cheap，show me the cod

https://github.com/LeonardoNve/sslstrip2

[cydysm]

反正不能明文就对了

[noobcoder1]

你让他加个密不就完了 前面+个密 后面加个盐 这样就能防止 cmd5 那种网站搞撞库解密

[noobcoder1]

@keepeye 这种做法上古时代了吧 现在都是前后分离 都是本地存 token 直接带过去鉴权的啊 没有直接重定向登陆的，如果登陆是有效的 直接跳到 next 后的地址就行了 不用手工点登陆了

[hakono]

@codehz 因为 .net .com 这些一般意义上的常用域名并不在内置的顶级域名里
虽然谷歌内置了 40 多个顶级域名，但实际上这些域名基本都是很少用的域名

可不是所有的网站都可以动不动换个域名的

[hspeed18]

不知道为什么那么多人觉得有问题。
如果没有用 https，前端加密了也没什么卵用。
如果用了 https，前端加密不是多此一举吗？

[ctblns]

你不把账号密码加密存储到数据库，你丢到 cookie 像被日啊

[codehz]

@nnnToTnnn #171 你看看你给的链接，只是原始的 SSLStrip 加一点改进的版本，还是 4 年前 HSTS Preload 还没实施的时候的仓库。。。

[nnnToTnnn]

@codehz 这是对抗 HSTS 的原理，因为 HSTS 是对于域名的。

[nnnToTnnn]

@codehz HTTPS 否认这个是漏洞，当然 sslstrip2 也不是针对 https 而是绕过 https 的 hsts，并非真正的解决了 https 的 hsts

[nnnToTnnn]

@codehz HSTS 依赖 dns 才能提供基础的域名服务。才能够正常访问网站 ， 确实 https 是足够安全，可是目前而言 dns 并非足够安全，而 HSTS 依赖 dns 这就让中间人有了攻击 https 的可能性了

[xuanbg]

要实现记住密码没问题，密码应该存本地，不应该让密码离开本地通过网络来存储，哪怕加密的也不行。

[Composurext]

借此问一下前端比好的加密方式是什么？就算加密后端拿到也要解密，是约定好的还是自己随便混淆一下

[cquan]

我记得最近出了一个密码法，到时候这种明文肯定是不允许的

[LeroyMooney]

@w99wen 学习了

[msg7086]

@hakono 我本来就不是在反驳你。基于论题展开讨论，从各方面进行探讨和补充，怎么就成杠了。贵站这个动不动就说杠的风气是真的不好，搞的人完全不想正常讨论下去了。要么还是专注于互喷吧。不回了。

[IvanLi127]

@lagoon #7 这段路，加不加密无伤大雅。存到数据库才需要加密