这是一个创建于 1848 天前的主题，其中的信息可能已经有所发展或是发生改变。
我不是前端，不懂也不敢问 eg: Cookie: userPwd=123456; userName=ws201907
 |
101
Allianzcortex 2019-11-01 06:39:48 +08:00
很多用户多个网站会用同一个密码，加盐 /加盐可以保证就算是这个密码在传输过程泄露了，用户的其他网站账户也相对安全。当然网站没有责任做这个
|
 |
103
Pastsong 2019-11-01 07:04:37 +08:00
@Allianzcortex HTTPS 就是来保证密码在传输过程不会泄露的，明文没有问题
|
|
104
Allianzcortex 2019-11-01 07:09:23 +08:00
@Pastsong 嗯，就是前面说的信道问题，往好处想预防类似以前的 12306 这样的自签证书？ belt & suspender
|
|
105
Allianzcortex 2019-11-01 07:10:59 +08:00
@Pastsong 服务器存密码明文的前车之鉴就是 CSDN
|
 |
106
laoyur 2019-11-01 07:43:44 +08:00 via Android
@msg7086 照你的理论，反正键盘记录器防不了，就啥安全措施都不用做了，别挣扎了，都明文好了，是这个意思吧？
|
 |
107
darknoll 2019-11-01 08:17:46 +08:00
用 httponly 还有 https，没什么卵事
|
 |
110
sevenzhou1218 2019-11-01 08:51:19 +08:00
我司也是啊，至少我们组的是，还好做的是公司内部项目，单点都是明文传输。
|
 |
111
KuroNekoFan 2019-11-01 08:57:00 +08:00 via iPhone
不对
|
 |
112
OnlyShimmer 2019-11-01 09:04:03 +08:00
其实在 cookie 放账号密码没什么问题,我个人猜测一下应该是要做记住账号密码 (我做过...)我一般都是 Bash64 转换一下再把敏感字换换( userPwd,userName)之类,这种东西真的是防君子不防小人,能黑你的人那肯定是知道这些,只能防防那些只知道按 F12 的人啦,心理安慰大于实际应用,再说因为有这一功能(记住账号密码)其实在密码输入框改一下 type 就能看到明文密码(本人健忘,经常这样干),如果不是记住账号密码这一功能,就当我放了个屁......
|
 |
113
NerverLibis 2019-11-01 09:06:53 +08:00 via iPhone
@lagoon 中间人攻击
|
|
114
NerverLibis 2019-11-01 09:08:38 +08:00 via iPhone
@mrdemonson 2028 位以上 dh 公钥才有点用，要不然几分钟就给破了
|
 |
117
zdnyp 2019-11-01 09:19:24 +08:00
https 也不是特别安全啊，看网络环境。没遇到过中间人攻击吗？如果是加密的，被截取到后端也认，那这个 cookie 也是有时限的，但是明文的，被截取到就任人宰割了。
|
 |
118
beastk 2019-11-01 09:24:25 +08:00 via iPhone
前端还是有必要加密密码等数据的，你们怕是没被撞库过。还民科，怕是没吃过亏吧。
|
 |
119
annielong 2019-11-01 09:28:58 +08:00
那百度的 BDUSS 不也是本地存，F12 复制出去就能用
|
 |
120
akakidz 2019-11-01 09:35:41 +08:00
后端不加密前端不都是多余的操作吗...顺便借楼问一下正确的前端加密方式～
|
 |
121
encro 2019-11-01 09:41:02 +08:00
1，cookie 会随着 http 请求头每次发送到服务器端，所以设置过多的 cookie 无形增加了传输带宽；
2，cookie 可以被客户端修改，明文存储容易被黑客修改后进入其他账户，比如将用户名或角色修改为 admin，从而拥有管理身份； 3，在传输过程中被拦截，因为各个地方接入服务商都是不干净的，现在 HTTP 网站被地方电信机房挂码概率为总体 20%以上，首次 80%以上，对方要拿密码是轻而易举的。 |
 |
122
liuzhiyong 2019-11-01 09:41:14 +08:00
当然不对啦。
|
 |
123
xuanbg 2019-11-01 09:44:22 +08:00
这种做法绝对是已经违法了。等保 2.0 了解一下
|
 |
124
killerv 2019-11-01 09:44:33 +08:00
我见过一个事业单位的网站，有个记住密码功能，做法就是密码扔 cookie 里……
|
 |
126
xiaokui 2019-11-01 09:45:36 +08:00
这不扯么？赶紧修改吧
|
|
127
akakidz 2019-11-01 09:55:35 +08:00
看了一下回复才明白楼主的意思，前端这样搞肯定是不行的:)
|
 |
128
qinxi 2019-11-01 10:00:42 +08:00
我见过 社交软件 用户列表返回值带明文密码的...
好在这家公司倒闭了 |
 |
129
chennqqi 2019-11-01 10:05:10 +08:00
首先不合规。
其次不安全，楼上的这些兄弟不要混淆 https 和加密。https 解决的是传输信道的安全，不是解决密码验证逻辑的安全。 还有楼上说的窃取 cookie 也可以获得登录权限的这种，窃取 cookie 和窃取密码是两种情况。你把密码存放到 cookie 里，别人拿了密码在哪儿登录都可以。你没有存放密码，别人窃取了 cookie，在 cookie 失效时就不能登录。另外如果服务端做了 cookie 客户端验证。也可以做到 cookie 其他地方登录无效的。 |
|
130
chennqqi 2019-11-01 10:06:42 +08:00  1
补充一下：说网站没有责任做这部分密码安全的请仔细读一下《网络安全法》，网络安全法实施后，这些是网站经营者的责任，由于网站经营者的责任导致用户损失的要承担法律责任
|
|
131
laoyur 2019-11-01 10:09:17 +08:00
@killerv 你说的那个站，可能是 @13725151469wy 哥做的
|
 |
132
component 2019-11-01 10:10:34 +08:00
安全感是自己给的，小伙子。
|
 |
133
keepeye 2019-11-01 10:11:23 +08:00
有的客户就是要求记住用户名+密码，下次不用手动输入，不是要记住登录状态，请问各位大牛前端该怎么实现才绝对安全？
|
 |
135
Yvette 2019-11-01 10:27:36 +08:00
@keepeye 不是前端不了解，不过至少所有我用过的国内国外的网站，没有任何一个是可以选择记住密码的，都是只有记住用户名或者登陆状态
|
 |
136
pkoukk 2019-11-01 10:42:37 +08:00
@msg7086
很多用户的账号密码是多网站通用的，不做任何处理记录在 cookie 里，有着明显的隐私泄露问题 上厕所的时候隔壁小哥看一眼你的电脑，就把你的账号密码抄走了，没问题么？ 确实对于前端来说，如果操作系统环境不受信任，任何加密都是无意义的。 但是又不是所有安全问题都出在操作系统层面上 |
 |
137
nnnToTnnn 2019-11-01 10:57:24 +08:00
@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 = 安全？ |
|
138
keepeye 2019-11-01 11:00:23 +08:00
|
 |
139
ihciah 2019-11-01 11:01:02 +08:00 via iPhone 1
贵司是出 ctf 题的吗
|
 |
140
fumichael 2019-11-01 11:01:51 +08:00
我觉得加盐加密更多是为了
部分用户不同网站设置密码都是一样的 + A 网站密码泄露的情况下，避免了 BCDEFGH…其他网站被一锅端了 同理，如果你把卡的密码都设置成一样，知道你一张卡的密码就知道了你其他卡的密码 加盐加密就对用户的原始密码保护了，减少了碰库的可能 以上都是我个人的想法，可能也有不对，仅供参考 |
 |
141
Mutoo 2019-11-01 11:12:33 +08:00
抛开传输上的问题来讲。cookies 最大的问题是会被明文存到本地，例如 chrome 是存在未加密的 sqllite 里。
(session cookies 除外) |
 |
142
codehz 2019-11-01 11:20:51 +08:00
|
 |
144
sujin190 2019-11-01 11:31:07 +08:00
不是据说密码法生效后，网站泄露用户密码是违法的么
楼上说网站没有责任为用户密码加密加盐，保证明文不会泄露窃取，你们是认真的么？谁说没责任了，作死也不能这么作吧 |
 |
145
zckevin 2019-11-01 12:03:00 +08:00
全站 HTTPS + HSTS
用户禁止 third-party cookies 可破 |
 |
148
msg7086 2019-11-01 12:22:58 +08:00
@nnnToTnnn 对于能执行植入根证书到系统这样的 root 级操作的人，或者能把 HSTS 从系统中剥离的人，请你找出任意一种不需要修改键盘硬件而能保护用户密码的手段。
如果你电脑的 root/最高管理员权限都被拿走了，你还跟我讨论 HTTPS 是否安全？建议先换一把门锁并重装系统，然后再看看这个神通广大的人有没有用伪基站和伪电信服务把你的整个互联网通信给中间人了。 |
|
149
msg7086 2019-11-01 12:30:41 +08:00
@fumichael 不需要密码原文的地方永远不应该存储某一种能够还原成密码原文的数据。
也就意味着网站的永久存储层里不应该用到任何「加密」算法，而应该用「散列」算法。 至于每次鉴权时，明文密码在不可信环境（互联网）传输时，使用 SSL 里的非对称的向前保密算法做加密保证可信信道，使用可信渠道（ CA 信任链）保证服务器端可信。这里是需要「加密」的。 这种情况下只有两种泄密可能。一是你电脑环境不可信，比如有木马，或者像上面说的被人往系统 CA 里下了药。再一个是服务器内部不可信，比如服务器被人黑了，替换了组件，把密码提前拦截了。 当明文密码安全到达服务器程序以后，程序就会加盐做散列（散列保证无法还原原文）。过了这一步以后，任何黑客都无法用这个来碰库了。 |
 |
150
hakono 2019-11-01 12:42:37 +08:00
@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，用户不更新浏览器依旧没用。 试问，有哪个公司能保证上自己网站的用户永远使用最新版的浏览器。 最终，解决这个安全问题的方法就是将安全维护再一次交回了开发公司和用户手上。 |
|
151
codehz 2019-11-01 12:47:27 +08:00
@hakono #150 所以我加上了 HSTS Preload(其实你只要用咕咕噜出的新 gTLD，他们自动就会在 preload 列表里，比如.new .app
为啥先说 HSTS 呢，因为没有 HSTS 就没有 Preload( |
|
152
msg7086 2019-11-01 12:53:41 +08:00
@hakono HTTPS 的安全措施是靠多方面努力的，是多方面合作产生的效果。
一定要说的话，如果把用户的网线直接拔了，接进专有网络里，什么都给你劫持干净了，又不给 HSTS Preload，又不让用新版的浏览器，那当然什么都没有用了。 另外，HSTS 对抗的是用户指明要求用 HTTP （即不输入 HTTPS://）的情况。在要求安全性的环境下，直接要求用户把完整的地址和协议输入进去，就不会产生这样的问题。 换句话说，这不是 HTTPS 的错，这是用户没有使用 HTTPS 的错。在危险环境下使用 HTTP，和打网址打错域名其实是类似的结果，只不过前者多一步劫持而已。如果某网上银行的地址是 「 https://bank 」 ，那么你输入「 bank 」或者 「 http://bank 」 就和输入 http://xxyyzz 一样危险。（所以这要么是网站没说清楚的锅，要么是用户没敲对的锅了。） |
 |
153
l4ever 2019-11-01 13:47:15 +08:00
你这算什么,我们公司的 api 直接 get 请求的用户名和密码, 牛的一皮. 还不是 http
|
 |
154
todd7zhang 2019-11-01 13:48:26 +08:00
前端加密的比喻就是
在家里大门 敞开( http) 的情况下, 是否还有必要将小房间的门锁(前端加密)上。 当然了小房间的门锁钥匙，有的就放在小房间门口(一眼就看到)，有的放在茶几下面(混淆 js) 所以，我觉得还是老老实实的关上大门吧 https |
 |
155
miniwade514 2019-11-01 13:57:32 +08:00 via iPhone
为什么要存密码呢？密码最安全的存储方式是用户的脑子🧠，要么就是以用户自己选择存到别的地方。写到 cookie 里面是无谓增加风险。
|
 |
156
no1xsyzy 2019-11-01 14:03:29 +08:00
@cheeto 所有用户数据在客户端加解密，服务器不存储任何形式的密码（连加盐版本也不存储），参考 Mega、Lastpass、ProtonMail 等，但相应的有如下弊端：
1、密码忘记不能找回账号内数据。你可以找回账号，但找回的只会是一个空账号，因为里面的数据只能靠之前的密码解密；唯一的解救手段是提供一个 Key 文件可以解密内容，但无法得到原密码，所以可以用 Key 文件找回之前的数据，但这一过程会清楚账号数据，所以拿到 Key 去拿别人账号必然被发现。 2、不符合中华人民共和国反恐怖主义法的需要。 |
|
157
hakono 2019-11-01 14:07:31 +08:00
@msg7086
你这就是抬杠了。我谈的是 HSTS 的问题，你跟我谈安全管理策略的问题。我们说的都不是同一件事，没看到我最后说的吗： “ 最终，解决这个安全问题的方法就是将安全维护再一次交回了开发公司和用户手上。” 这就是你谈的这些内容。 顺便，你有点搞错论题了，我只是路过吐槽你这一句话 “对于能执行植入根证书到系统这样的 root 级操作的人，或者能把 HSTS 从系统中剥离的人，请你找出任意一种不需要修改键盘硬件而能保护用户密码的手段。” 要从 HSTS 方面下手，根本不需要把 HSTS 从系统中剥离，也根本不需要入侵到对方系统中，我吐槽的是这点 |
|
158
no1xsyzy 2019-11-01 14:07:49 +08:00
@mrdemonson 数据库加密并不能防运维和开发，Facebook 前车之鉴，会把明文密码打 log
|
|
160
codehz 2019-11-01 14:15:42 +08:00
@hakono #159 你也没看我括号的内容） gTLD 在 preload list 里的情况下，所有用这个 tld 的都能自动获得 hsts 加成，并不需要 4 个月的问题）
|
|
161
no1xsyzy 2019-11-01 14:23:27 +08:00
但是其实还要担心一点：现在大部分服务器是运行在 VPS 上的，实际上如果过程中以明文存储在内存上，如果 VPS 提供商扫描内存的话是可以知道密码的。试问在座有几个人会对自己服务器上传入的数据在 HTTP 层面先做随机化分布？（即 SSL/TLS 层解密后在内存位置是打乱的）
Cookie 的另一个问题就是反授权时 token 之流方便一点，存用户名密码就需要重置密码了。 |
 |
165
w99wen 2019-11-01 14:48:16 +08:00 1
@fumichael
对于加密 有两个基本概念：对称加密，非对称加密 对于 hash 之类的，其实是取得摘要，指纹，或者说特征值，不是加解密。 每个固定内容，特征值应该是唯一的。同时我们不能直接从特征值得到原内容，除非你计算过或者说记得这么一个对照表，有这些一一对应关系。 但是这其中有一个问题，大部分需要取摘要的内容都很短，很容易被人们计算出来，并且保存到对照表中（这个表，就叫彩虹表），所以才要加盐，加上一段随机字符，将内容变长，比如扩充到 50 位，那这个 50 位的彩虹表，就已经无法建立了，太大了。 加盐，是为了对抗彩虹表。这个是根本目的。 |
|
168
no1xsyzy 2019-11-01 14:54:30 +08:00
@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 万，就是十几天，还多半不会命中。 |
|
169
no1xsyzy 2019-11-01 15:06:01 +08:00 1
@w99wen 彩虹表不是对照表，而是一个依赖于特定的哈希函数 hash 和随意指定的、反转了定义域和目标域的函数（实质上是另一种 hash，不过通常生成的是变长字符串） rehash 构造的简化对照表，它的结构和 hash 强对应，
彩虹表就算你在 6 位数字上加一位数字的盐，因为哈希算法被改变 new_hash = d=>hash(salt+d)，导致整个彩虹表不可用，但对照表的话刚开始就构造 7 位对照表的话还是可以使用的。 这就是为什么需要每个用户独立生成盐，否则还是可以用彩虹表。 |
 |
170
kiracyan 2019-11-01 15:24:12 +08:00
明文保存密码都是弱智.不管在哪
|
|
171
nnnToTnnn 2019-11-01 15:25:09 +08:00
@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 |
 |
172
cydysm 2019-11-01 15:31:40 +08:00 via iPhone
反正不能明文就对了
|
 |
173
noobcoder1 2019-11-01 15:59:24 +08:00
你让他加个密不就完了 前面+个密 后面加个盐 这样就能防止 cmd5 那种网站搞撞库解密
|
|
174
noobcoder1 2019-11-01 16:09:28 +08:00
@keepeye 这种做法上古时代了吧 现在都是前后分离 都是本地存 token 直接带过去鉴权的啊 没有直接重定向登陆的，如果登陆是有效的 直接跳到 next 后的地址就行了 不用手工点登陆了
|
|
175
hakono 2019-11-01 16:14:59 +08:00
|
 |
176
hspeed18 2019-11-01 16:19:52 +08:00
不知道为什么那么多人觉得有问题。
如果没有用 https，前端加密了也没什么卵用。 如果用了 https，前端加密不是多此一举吗？ |
 |
177
ctblns 2019-11-01 16:22:46 +08:00
你不把账号密码加密存储到数据库，你丢到 cookie 像被日啊
|
|
178
codehz 2019-11-01 16:25:41 +08:00
@nnnToTnnn #171 你看看你给的链接，只是原始的 SSLStrip 加一点改进的版本，还是 4 年前 HSTS Preload 还没实施的时候的仓库。。。
|
|
180
nnnToTnnn 2019-11-01 16:41:20 +08:00
@codehz HTTPS 否认这个是漏洞，当然 sslstrip2 也不是针对 https 而是绕过 https 的 hsts，并非真正的解决了 https 的 hsts
|
|
181
nnnToTnnn 2019-11-01 16:44:02 +08:00
@codehz HSTS 依赖 dns 才能提供基础的域名服务。才能够正常访问网站 ， 确实 https 是足够安全，可是目前而言 dns 并非足够安全，而 HSTS 依赖 dns 这就让中间人有了攻击 https 的可能性了
|
|
182
xuanbg 2019-11-01 16:47:28 +08:00
要实现记住密码没问题，密码应该存本地，不应该让密码离开本地通过网络来存储，哪怕加密的也不行。
|
 |
183
Composurext 2019-11-01 17:06:35 +08:00
借此问一下前端比好的加密方式是什么？就算加密后端拿到也要解密，是约定好的还是自己随便混淆一下
|
 |
184
cquan 2019-11-01 17:40:18 +08:00
我记得最近出了一个密码法，到时候这种明文肯定是不允许的
|
 |
185
LeroyMooney 2019-11-01 17:57:13 +08:00
@w99wen 学习了
|
Select Language