这是一个创建于 1848 天前的主题，其中的信息可能已经有所发展或是发生改变。
我不是前端，不懂也不敢问 eg: Cookie: userPwd=123456; userName=ws201907
 |
1
wenzichel 2019-10-31 17:41:57 +08:00
赶紧开了吧，早晚得出事儿
|
 |
2
agdhole 2019-10-31 17:44:06 +08:00
早晚得出事儿
|
 |
3
usw 2019-10-31 17:44:30 +08:00  1
我们用 httponly，约束自己不要乱搞 cookie
|
 |
4
littleylv 2019-10-31 17:44:40 +08:00 15
你是真问还是假问的？
如果真问，你也…… |
 |
5
wispx 2019-10-31 17:45:03 +08:00
是个狼人
|
 |
6
turi 2019-10-31 17:46:35 +08:00 1
报公司名吧 ，以后绕着走
|
 |
7
lagoon 2019-10-31 17:46:37 +08:00 4
我已经淡定了。
我还记得某次某个项目问后台，传输过程中账号密码不做个加密吗？答：为什么要加密？ 我还记得和同事争论了半天，加密到底有没有用。 现在，我也开始反问，干嘛要加密？ 出事？出事的锅大概率不在你身上。 用户？用户在意这些吗？ 领导？领导在意这些吗？ 逐渐混沌邪恶。 |
 |
12
mmixxia 2019-10-31 17:53:03 +08:00
有比较大的安全隐患
|
 |
13
opengps 2019-10-31 17:54:30 +08:00
挺好，将来绝对不用你背锅
|
 |
14
katsusan 2019-10-31 17:55:20 +08:00
那后台存数据库的时候呢，最好也看看。 好像说国家有条例规定不能明文存敏感信息
|
 |
16
sheeta 2019-10-31 17:55:55 +08:00
赶紧跑路
|
 |
20
Kerwin1202 2019-10-31 17:59:29 +08:00
没毛病
|
 |
24
tinycold 2019-10-31 18:02:17 +08:00 via Android 1
@littleylv 没意义，你加密了密码，别人拿到加密后的密码根本不用解密，照着这个请求发过去你后端还是要认！
|
 |
27
exiaoxing 2019-10-31 18:09:22 +08:00
记得当年考驾照登录过一个网站，用户名和密码都在 url 里
|
 |
28
dmjob2015222 2019-10-31 18:11:50 +08:00
你司肯定有大神坐镇
|
 |
29
luozic 2019-10-31 18:14:14 +08:00
得出事儿
|
 |
32
rykka 2019-10-31 18:18:11 +08:00 via Android
不知道为什么要存 cookie。
用 session 不行？我觉得这个锅不是产品就是技术经理的 |
 |
33
cheeto 2019-10-31 18:18:46 +08:00
借楼问一下正确的前端加密方式～
|
 |
34
loveour 2019-10-31 18:19:01 +08:00
必然不对。如果是我就怼，解决不了就离职。我觉得也不能只是工作，多少也得有点追求有点信念吧。有些事情可以忍，有些事情忍不了。
|
 |
35
userdhf 2019-10-31 18:19:19 +08:00
前端没有安全性可言。。
|
|
36
rykka 2019-10-31 18:21:50 +08:00 via Android
目测 lz 不是前端，不知道是做那一块的。
如果不熟悉建议让技术负责人定。 不要一上来就标题党 |
 |
37
YUyu101 2019-10-31 18:24:16 +08:00 via Android
前端是用户的，用户泄密你拦不住，服务端是公司的，公司泄密才是你能管的。前端为什么存密码才是问题，难道除了登录还有什么服务需要密码吗？
|
 |
38
yuang 2019-10-31 18:24:27 +08:00 via Android 4
我司也是，我说了没用，是说为了实现记住密码功能才这样做的。记住密码功能是这样做的吗
|
 |
39
alw 2019-10-31 18:25:51 +08:00 2
反正我做项目时，用户在前端输入密码时就加盐 hash 一次，传输到后端保存或验证密码时再加盐 hash 一次，不管怎么样，绝对不允许出现用户密码明文在任何环节保留。
|
 |
40
taogen 2019-10-31 18:26:30 +08:00 via iPhone
前端为什么要操作 cookie，cookie 不是后端写入用来保持 http 请求的用户状态吗？前端传参数不是用 request body 吗？
|
|
42
littleylv 2019-10-31 18:30:53 +08:00 1
@alw #39 那么我问你，“用户在前端输入密码时就加盐 hash 一次”，这个盐，你是不是写在 js 了，那别人不就知道了？所以跟没加密不是一样？
后端加密的好处就是别人根本不知道你的盐 |
 |
43
nieyujiang 2019-10-31 18:32:07 +08:00
是个狼灭
|
 |
45
mrdemonson 2019-10-31 18:39:43 +08:00 via Android 7
加密其实都是针对特定人加密的，
https 是防网络中间人， 数据库密码加密是放黑客、防运维、防开发， 前段密码加密无实际意义，但也绝不能把密码放 cookie 里面 |
 |
46
crclz 2019-10-31 18:44:36 +08:00 2
这个做法问题不大。cookie 中放<token>和放<明文密码>，大多数时候唯一的区别就是取消一个设备对账号的访问权必须修改密码，而采用 access-token 就只用废除 token 即可。其他的关于加密、窃取方面的行为都是没区别的。
即使要甩锅，也是后端的锅：不应该提供 cookie 中明文密码认证的途径。管前端吊事。 微软 asp .net core web 框架的做法是：cookie 附带一个 claim 和 security-token。claim 就是服务器签发的用户名的证明，好像是带签名（ username+signature ）的，密钥存在哪里我没有深究。security-token 每改一次密码或者重新绑定一次电话号码等都会变一下，这样就可以实现账号安全信息变更时自动废除之前的访问权，并且不用向用户呈现“token”或者设备的概念，只需修改密码或者电话号码就一切安全，比较符合自然的逻辑。 |
 |
47
tomczhen 2019-10-31 18:48:22 +08:00 via Android
记住密码这个机制应该是浏览器控制的，用户可控。对 Web 应用而言记住登录状态不应该是记住用户口令与密码明文，而是一个凭证，也就是 token 或者别的什么。
但是这个凭证确实不用加密。 |
 |
49
aWangami 2019-10-31 18:54:50 +08:00 via Android
我猜锅是后端的，前端也只是被逼无奈
|
 |
50
superrichman 2019-10-31 19:01:59 +08:00 via iPhone
这是个严重的安全隐患
|
 |
51
Mohanson 2019-10-31 19:02:23 +08:00 12
@lagoon
复制一段以前我发过的话: 最近正好接触密码学，简单和回答一下：在信道安全的假设下，对通信数据做加密是没有意义的。比如你登录远程 linux 服务器，你是直接输入明文密码的。而在信道不安全的情况下，对通信数据加密有意义又没有意义：因为你必须把密钥通过信道传送给对方。 所以世界上正经的计算机科学家都在解决信道安全问题： https, ssl, tls 等，(删掉)而剩余的民科则在研究前端加密(删掉) 原文见: https://www.v2ex.com/t/608692#r_8018696 |
 |
52
laoyur 2019-10-31 19:04:53 +08:00 1
@littleylv > 这个盐，你是不是写在 js 了，那别人不就知道了？
注意他说的 hash 一词，别人能知道你的前端处理逻辑，也能拦截到 hash 后的值，但没法知道用户输入的原文啊 |
 |
53
hundan 2019-10-31 19:16:40 +08:00 via Android 1
嗯 我想了想 既然是前端背锅 那么一定是输入密码的时候 js 记录 那么一定是没有 httponly 的 且不说日志里面是不是可能存了一大堆这种数据 一旦界面有 xss 之类的 就可以获取账号密码了 都不用做持久化
这里对话上面的程序员们 有些人觉得 上个 https 防中间人就好了 你们知道有种东西叫做隐患 此外密码和 session 不同 密码是长期的 甚至可能多网站通用 以及可能包含用户信息 |
 |
54
lihongjie0209 2019-10-31 19:17:10 +08:00
@laoyur #52 没必要用原文啊， 直接模拟请求发送 hash 之后的值给服务端， 服务端无法区分的
|
 |
55
index90 2019-10-31 19:24:02 +08:00
cookie 放敏感信息（密码，密文，token，key ），其实都没有问题，问题是明文。
这里的明文是指用户所输入的字符串信息，原封不动地存储在 cookie 中，那么即有可能被泄露。 正确的做法是，前端存储加盐哈希后的密码，这样文本存储在 cookie 中是没有问题的。这里就需要后端登录接口，所接受的密码字段，是哈希后的密码。所以这里后端可能也要背锅。 |
|
56
index90 2019-10-31 19:26:33 +08:00
补充：
LZ 所提的问题不是传输安全问题，不需要在中间人挟持或密码传输安全等问题上讨论。这些问题的答案我觉得#51 说得很好。 这里的问题，应该是客户端信息安全问题。 |
|
57
laoyur 2019-10-31 19:35:15 +08:00
@lihongjie0209 你没看懂 @alw 哥的意思，他这么做是为了 [保护用户密码明文] ，不是说为了防止传输过程中被截取（传的是 hash，截取了也泄露不了密码明文）
|
 |
59
cyssxt 2019-10-31 19:40:28 +08:00 via iPhone
前端加密意义是什么？代码都功能开的的，谈什么加密
|
 |
60
cp19890714 2019-10-31 19:41:11 +08:00
@lagoon 加密肯定会更安全些, 但是既然加密了, 干嘛不直接用 HTTPS
|
|
61
laoyur 2019-10-31 19:43:07 +08:00
@index90 > hash 不等于加密
没错，你说的对。但是跟我说的有什么关系吗？ 我只是在阐述，alw 的做法，是为了让任何环节（键盘记录器、屏幕识别除外）都不泄露出用户的原始密码，我对这种做法表示赞同。 |
|
62
cp19890714 2019-10-31 19:43:46 +08:00
@lagoon 前端不仅要加密, 还要加盐,随机码,防止重放攻击, 麻烦的一比. 且大多是防君子不防小人.
真正想安全, 还是得 HTTPS |
 |
63
w99wen 2019-10-31 19:45:31 +08:00 1
不对。
不敢怎么样，token 不是密码，token 可以失效，token 可以在用户异常 ip 变更的时候设置为失效。 密码不能，只要是账号密码正确，哪怕一秒钟换 10 个 ip，也不能设置密码为失效。 所以，暴露密码，绝对不对。 |
|
65
index90 2019-10-31 19:50:02 +08:00
|
 |
66
cuzfinal 2019-10-31 19:54:37 +08:00 via Android
明文放哪都不对
|
 |
67
wangxin13g 2019-10-31 19:55:52 +08:00
前端加盐 hash 意义是避免中间人攻击直接获取传输的明文账号和密码，但是无论前端是否加密 账号密码都不能放在 cookie 内的
|
 |
68
ksharp8 2019-10-31 19:59:55 +08:00
一般要加密加盐加时间戳
|
 |
69
sunzongzheng 2019-10-31 20:00:34 +08:00 via Android
密文防撞库
|
 |
70
hyy1995 2019-10-31 20:01:19 +08:00 1
他该不会是想做“记住用户名和密码”这个功能吧。。。这也太骚了
|
 |
71
yxwzaxns 2019-10-31 20:04:27 +08:00
前端加盐做个 hash 是对用户的尊重，表示我对你的密码内容没兴趣（此条只针对密码有意义或隐私的用户）
|
 |
72
hirasawayui 2019-10-31 20:05:21 +08:00
我司项目上了 https，但还是要求接口入参加密。。。。 请问这有必要吗？
|
 |
73
hushao 2019-10-31 20:18:37 +08:00 via iPhone
密码在整个系统的流程中只有登陆和重置两种交互用的到...所以问题应该是为嘛要存在 cookie 而不是明文不明文...🤣
|
 |
74
xavierskip 2019-10-31 20:19:14 +08:00
无论如何都不能明文存储用户密码。不管在那里。
|
 |
75
skylancer 2019-10-31 20:26:02 +08:00
存密码是傻子，无论是明文还是 hash 甚至加盐后的都不行
为什么不选择 session, 验证有问题直接 revoke 就搞定了 |
 |
76
x66 2019-10-31 20:26:02 +08:00
@hirasawayui #72 没有必要，https 已经保证了信道安全。
|
 |
77
shansing 2019-10-31 20:26:21 +08:00
@Mohanson 信道安全不安全不能一概而论，看是要防止窃听者还是中间人。诸如 DH 这类密钥交换算法，可以在不安全的信道中安全地交换密钥，不过不能防止中间人攻击。
|
 |
78
Varobjs 2019-10-31 20:43:34 +08:00 via Android 1
这个还不是最骚的
上个公司 (上市的) 他们活动页面，需要手机号验证码的，直接把验证码明文存 cookie，然后 js 比较 cookie 与用户输入是否一样来校验的。 |
 |
79
geekdocs 2019-10-31 20:45:26 +08:00
我想知道什么样的需求要存密码呢？
|
|
80
Varobjs 2019-10-31 20:45:56 +08:00 via Android
另外 cookie 存密码做什么？方便 debug ？🐶
|
 |
81
Nicoco 2019-10-31 20:49:14 +08:00
从入职到入狱……
|
 |
82
paulzhang1992 2019-10-31 20:56:03 +08:00
也许只是个假的呢😂
|
 |
83
shuichengjian 2019-10-31 21:11:02 +08:00
前端路过。。。
前端加密，一般混淆视听，没有多大意义。但实际操作还是会加密。 这位老哥的问题在于： 把明文密码直接存 cookie。 不管出于什么需求，都不能这么做。 且个人意见： 完全看不到这样做的意义。 |
 |
84
phantomzz 2019-10-31 21:18:26 +08:00
难道没人怀疑，既然前端直接存明文，后端是不是也用的明文？不然意义何在？
|
 |
85
lp10 2019-10-31 21:24:55 +08:00 3
cookie 存明文密码跟桌面搞个 txt 存密码没有任何区别
都需要被吊起来打 |
 |
86
areless 2019-10-31 21:28:05 +08:00 via Android
是哦，现在 https 了。像以前的 md5 之类的摘要传到后端对比或者创建 session id~~~api 用 key 去混进值里面尾部加所有字符串的 md5 摘要校验真没必要了呢。嘻嘻~~~
|
 |
87
likuku 2019-10-31 21:37:42 +08:00
对不对？安全原则之一：
加密所有的一切 |
 |
88
arayinfree 2019-10-31 21:42:39 +08:00
对用户个人的隐私暴露增加风险, 如果亲戚同事朋友使用电脑看到 cookie 这些信息就把你密码暴露了.
如果密码不是明文的话就还好. |
 |
89
mcrwayfun 2019-10-31 21:43:33 +08:00 via iPhone
12306 登录接口也是明文
|
 |
90
LokiSharp 2019-10-31 22:06:07 +08:00
其实没啥大问题，浏览器本身的密码储存的也是明文。
|
 |
91
ironMan1995 2019-10-31 22:29:37 +08:00 via Android
cookie 不是服务端发送的响应报文中的首部字段通知客户端保存的，之后每次请求都带上的么，所以你们用这个要解决什么问题？
|
 |
92
iMusic 2019-10-31 23:14:47 +08:00
跟他说：你好骚
|
 |
93
vmebeh 2019-10-31 23:17:59 +08:00 via iPhone
后端把收到的参数都存到 log 里面去了，于是密码明文存在 log 中
|
 |
94
ljpCN 2019-10-31 23:34:28 +08:00 via Android
登录的时候，是不是前端发送请求时，把密码用时间戳加密一下，后端用前端给的时间戳对称解密，这样是一种解决方案？一来没有明文，二来避免重放攻击，除非加密解密方法泄露了。
|
 |
95
newtype0092 2019-11-01 00:06:39 +08:00 1
@Mohanson 前端在用户输入时对密码做哈希（不是加密！）这个不是密码学问题，而是社会工程学问题。。。
不管什么途径，用户的明文密码流入服务器就是对用户隐私的不负责任。 |
 |
96
2643595423 2019-11-01 00:26:26 +08:00 via Android
就是数据库也不能明文储存啊
|
 |
97
wolfan 2019-11-01 00:28:48 +08:00
要不你委婉提醒下好打 MD5 一下也成不是。
|
 |
98
Kbyte 2019-11-01 02:01:28 +08:00
@Varobjs 这种我也遇到过，甚至是大公司一个项目的主要登陆页面。直接从 cookie 里读取验证码明文，那费劲吧啦做个验证码不知道有啥意义，可能只能确保用户不走神儿吧
|
 |
99
BaiLinfeng 2019-11-01 02:24:38 +08:00
所以 cookie 和 token 有何区别
|
 |
100
msg7086 2019-11-01 04:27:08 +08:00 3
@alw @laoyur @index90
> 任何环节（键盘记录器、屏幕识别除外） 所以以前游戏盗号用得最多的键盘记录器就让你给除外了？ > 绝对不允许出现用户密码明文在任何环节保留。 最理想的情况是键盘内部加密，敲字符的时候直接通过某种算法进行转换，输入到文本框的直接就是密文，如果你不信任这台电脑的话，明文字符根本不能进到电脑里。 如果你假定这台电脑是不安全不可信的，那么进了电脑以后再加密并不能解决安全问题。 如果你假定这台电脑是安全可信的，那么只需要在离开电脑进入公共网络的时候加密（ SSL ）即可。 在假定安全可信的环境里额外增加安全措施没有什么意义。 除了一种情况。 就是你不信任自己的服务器，怕自己服务器被人黑了会被人拿到用户的原始密码，所以决定不让原始密码进到自己的服务器里。 这种情况我建议咨询网络安全团队…… |
Select Language