这是一个创建于 1285 天前的主题，其中的信息可能已经有所发展或是发生改变。
有一些敏感数据（非密码）要客户在网页提交，网站是 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 前向加密
|
Select Language