有一些敏感数据(非密码)要客户在网页提交,网站是 https,我知道密码可以公钥加 sha1 再传输,反正私钥在我后端对比就好。 但是非密码敏感数据,后台要能拿到原文的,请问 1 ) https 了,前端还需要对称加密吗? 2 )需要的话,用什么方式来加密?网页源码能看到加密算法吗?
谢谢。
1
Quarter 2021-05-22 10:29:54 +08:00 via iPhone
想要看不到(直接看到)源码,需要对源码进行混淆
想要知道加密是为了防止什么情况发生? |
2
codehz 2021-05-22 10:37:29 +08:00 via Android
主要看你的威胁模型
反正只要记住能 mitm 攻击 https 的,肯定可以轻易修改内容,别说偷你加密密钥了,直接把前端加密给扬了,然后它自己偷了再加密然后传递给服务端都可以。。。 |
4
noe132 2021-05-22 10:41:48 +08:00
前端加密 = 不相信浏览器
不相信浏览器 = 认为脚本可能会被替换 /篡改 脚本可能会被替换 /篡改 = 加密等于没有加密 |
5
yin1999 2021-05-22 10:42:43 +08:00
前端做二次加密感觉意义不是很大,隔壁 GitHub 在 https 登录时都是没做前端二次加密传输密码的
|
6
ladypxy 2021-05-22 10:50:16 +08:00 via iPhone 4
前段加密没有任何实际意义
|
7
wanguorui123 2021-05-22 11:00:19 +08:00 via iPhone
简单的 Salt+SHA 不向服务器提交密码还是有必要的。其他没什么实质性的安全提升
|
8
580a388da131 2021-05-22 11:11:51 +08:00
不信任客户端环境的话,什么加密都没用。
加密算法的脚本对客户端是透明的,否则就没办法运行了。 真的特别需要的话,应该调用实体 usb key 加密。 |
9
fxrocks OP 感谢大家回复
|
11
yin1999 2021-05-22 13:40:06 +08:00
@EminemW 楼主说的是要拿到原文的(真打印参数也不会打印密文),而且日志打印参数这个和部署前没有没有认真去审查也有关系吧
|
12
fano 2021-05-22 13:57:30 +08:00
whatsapp 、telegram 的网页版做了二次加密
|
13
liuidetmks 2021-05-22 16:07:38 +08:00
@fano 可能是他们是端到端的加密吧,所以需要网页加密
|
14
crab 2021-05-22 16:09:29 +08:00
前端加密网页可以跟出加密算法啊
|
15
ch2 2021-05-22 16:22:55 +08:00
前端加密一般是用来反机器人的,你不需要反机器人就不用加密
至于明文能不能看到,加了 https 以后攻击就足够难以实施了,不必过于追求这个 |
16
kappa 2021-05-22 16:33:12 +08:00
@liuidetmks Telegram 默认不是 e2e
|
17
009694 2021-05-22 16:38:39 +08:00 via Android
前端加密其实是有意义的。 也就是不信任后端。。比如把明文密码写在 log 里这种行为
|
18
Maskeney 2021-05-22 17:23:38 +08:00 via Android
https 是保证通信过程不被第三方窥探,如果你的内容需要对客户端也保密的话,那么需要
|
19
brader 2021-05-22 18:16:17 +08:00
https 的话,已经是传输安全了,所以再次加密,解决的不是传输安全问题。
再次加密一些敏感数据,可以增加别人的破解难度,还能使得别人无法随心所欲的使用一些工具直接构造请求,可拦住一些初级攻击人员。 说回正题,公司对这块接口安全级别要求比较高的话,可以选择加密。客户端是能被获知源码来分析加密算法的,所以你采用对称加密,也是有办法解密的,对称加密优点是解密速度快、没有长度限制。如果采用非对称加密,优点是被截获后是无法解密的,缺点是能加密的明文长度有限、解密消耗资源多。 |
20
muzuiget 2021-05-22 18:43:56 +08:00
前端加密只是防服务器资源被滥用,至少提高攻击成本,纯粹是放中间人的,HTTPS 就够了。
|
21
DefoliationM 2021-05-22 19:25:21 +08:00
前端加密有屁用 别人都能看到源码
|
22
opengps 2021-05-22 19:38:25 +08:00
多少有些用途,虽然前端的逻辑等同于白盒,但是做了相对于不做,是对小白用户的最大阻挡,就好比图形验证码一样,我非常不看好那种复杂的静态的图形验证码,因为只要是静态,依然是防君子不防小人
|
23
johnsona 2021-05-22 20:50:43 +08:00 via iPhone
反爬虫
|
24
fox0001 2021-05-22 21:09:06 +08:00 via Android
前端加密数据,可以看看 wasm 或者 WebAssembly 。目前所有的主流浏览器都已经支持 WebAssembly V1 ( Node >= 8.0.0 )
|
25
no1xsyzy 2021-05-22 23:25:13 +08:00
如果客户端能被篡改,什么都没用的,直接 $(`input[type="password"]`).on('change', imposter) 不香吗?
但有一些攻击模型下,客户端可能会被中间人尝试篡改,但篡改失败的情况,比如通过 CSP 和 subresource 校验,曾经在可信网络条件下访问过,以后就可以在不可信条件下访问而确认没被篡改;或者也有 service-worker 去做第二重加密的办法。但这两个对服务可用性的影响太大,比如之前 Trello 的 service worker 会把在第二次加载时把页面搞崩(我是拿 ublock 精确匹配屏蔽了 worker 就自动解决了……) @EminemW 我怀疑你在影射 Facebook |
26
3dwelcome 2021-05-22 23:46:45 +08:00
学 figma,前端网页一部分是渲染后的 canvas,这样的方式有天然的前端数据加密特性。
|
27
rockyliang 2021-05-23 11:23:52 +08:00
主要看你想要防范的攻击类型,如果只是想防御中间人攻击,用 https 就可以了。如果还要防止别人恶意调用你的后端接口,再做一次对称加密会好一点,这样别人还要破解你的客户端,看你的前端代码,才能知道加密方式,会增加一点难度
|
28
MakHoCheung 2021-05-23 15:10:17 +08:00
看到你说“密码可以公钥加 sha1 再传输”,现在我反而想问问已经使用 https 了,为什么还要对密码进行加解密呢,有什么安全问题吗
|
29
zhuweiyou 2021-05-24 11:09:50 +08:00
前端加密没有意义,代码都是"公开的".
如果是为了服务器日志啥的, 倒是可以考虑. |
30
guanyin8cnq12 2021-07-08 11:41:57 +08:00
tls1.3 前向加密
|