求教各位安全大佬，从安全角度来说，密钥似乎只能一层套一层解决？
有个场景：前端要给后段传递一个敏感值 称为 A 。
一种可行的解决方案是（已经开启了 HTTPS ）：
后段提供一个接口获取公钥（假设是一随机串），前端调接口拿到公钥加密 A ，得到 A+ 然后 A+ 给到后端用私钥解密。这样安全吗
 | 1 z7356995 10 小时 17 分钟前 via Android 我觉得 https 就更安全了，解决了中间人攻击，再复杂就觉得是化蛇添足了 |
 | 2 jacketma 10 小时 15 分钟前 没有。就算有一种绝对安全的方式，至少还要记住这种方式是啥。就像有人忘记密钥存在哪里了，只有天晓得了 最终还是必须要有一段信息靠大脑记忆、或者生物信息识别。 |
 | 3 fun201108 10 小时 14 分钟前 看 https 的原理 |
 | 4 e3c78a97e0f8 10 小时 7 分钟前 如果 HTTPS 安全，你这完全是无效操作 如果 HTTPS 不安全，中间人攻击后完全可以替换你返回的公钥，你也是无效操作 HTTPS 已经是安全的最优解了，任何其他操作都是重新发明 HTTPS 如果你真的很在乎安全性，可以加上客户端证书进行验证 |
| 5 e3c78a97e0f8 10 小时 6 分钟前 更正一下，TLS 已经是安全最优解，HTTPS 是 TLS 的一种常见应用 |
 | 6 pingdog 10 小时 4 分钟前 via Android CS/BS ，C/B 用公钥加密，S 用私钥解密 这…… 防中间人？ HTTPS 就防了 防 C/B 篡改请求？直接 hook 替换加密前的文本，或逆向加密请求 |
 | 7 itechify PRO 没有绝对，防不住有心人 |
 | 8 facebook47 9 小时 48 分钟前 via Android 前端加密，多此一举有门槛，但没用 |
 | 9 unused 9 小时 45 分钟前 via Android 一次一密的量子通信 |
 | 10 leo72638 9 小时 44 分钟前 via iPhone 任何东西加个绝对那就是没有 |
 | 11 seers 9 小时 34 分钟前 via Android 在 HTTPS 上面再自己实现一遍基础的密钥交换就行，抓包只能看见公钥和密文，无法解密，配合客户端混淆/反调试等手段，可以杜绝大部分攻击了 |
 | 12 COW 9 小时 10 分钟前  1 > 密钥似乎只能一层套一层解决？ 实际上加密层数量并不是越多就越安全，密钥算法 != 加密层数量，如何选择密钥、如何存储密钥才是更应该优先考虑的点。 > 后段提供一个接口获取公钥（假设是一随机串） 公钥是和私钥根据算法一块生成的，不理解你说的随机串是什么 > 前端调接口拿到公钥加密 A ，得到 A+ 然后 A+ 给到后端用私钥解密 通常从效率考虑，不会用公钥去加密数据，而是用对称密钥去加密数据，公钥用来加密对称密钥 |
 | 13 Ketteiron 9 小时 1 分钟前 1 前端加密解决的是敏感，而不是安全 (无法以任何手段保证绝对安全)，即原始明文是否应该发送到服务端，对用户来说是一件敏感的事。 (虽然服务端并不会储存原始明文，csdn 这种傻逼公司很好地说明了储存明文密码不会带来任何益处反而后害无穷) 前端加密只需要任何一种不可逆算法就行，不要考虑太复杂的东西。 |
 | 14 cppc 7 小时 8 分钟前 如果应用层要做： 1 使用临时密钥，比如密钥协商算法协商一个特殊用途的会话密钥 2 最终会需要一个类似根钥的密钥，这个在硬件中才能具有很高的安全性 3 没有绝对安全，只有层层加码 |
 | 15 ZeroClover 6 小时 47 分钟前 2 密码学第一原则：不要自己发明密码学 顺便，最近在前端密码学上有一定的突破，但绝对不是你这么简单的方案就能正确、安全地实现的。参考： https://blog.cloudflare.com/improving-the-trustworthiness-of-Javascript-on-the-web/ |
 | 16 Benjamin007 4 小时 38 分钟前 没有绝对安全方案，你说的方案能增强安全，但仍需防范公钥伪造等风险。 |
Select Language