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