接口加密问题

[XuYijie]

亲爱的同僚们，我目前在学习接口加密，就是请求参数和返回值加密，假如使用 rsa 的话：服务端生成一个密钥对，前端生成一个密钥对，互相交换公钥，就可以使用彼此的公钥和自己的私钥进行加密解密了，问题是前端的私钥存在哪里呢？放在代码里，本地存储里，cookie 里，都有被盗取的风险吧，难道是不存储密钥，每次调用接口都要临时生成秘钥吗？

[sampeng]

这个问题 v 里面讨论过很多次了。https 对链路的安全保证已经足够了。
你要是考虑本地存储，cookie 被盗。首先，这两个东西被盗本身就是一个伪命题。1 ，成本巨大，只有电脑被黑中毒着一种情况。所以没人把密码存着里面。2.为啥要服务端返回什么你就存什么呢。你就不能自己再用 js 加密一次？你要是总是想着反编译就能看出逻辑来。。实话实说，99%的人做不到。

第三，这种问题没必要自己猜和想，学习他人经验就好了。你的业务量再大有 aws 的业务量大？有他的安全性要求高？ aws 的这些东西泄漏就是很多很多很多钱。。aws 的 client 都是现成开源的，分析 client 的请求签名逻辑就好了。aws 的接口内容都不需要加密。为啥你的接口需要？只需要保证 1 ，走的 https 。2 ，有签名确保是从可信 client 发出来的。接口安全到这个级别就够了。否则。。。拉 vpn 吧。。。。。

[ianisme]

加解密没有绝对的安全，只是为了做到相对安全，例如黑客他掌握了反编译、动态调试等技术，可以模拟出一个客户端的所有请求去和服务端交互，甚至对于 APP 来说直接 hook 相关代码把解析后的明文日志直接拿到都省略破解密钥这步了。

[ianisme]

@soar0712 和 @ren2881971 讲解的很清晰

[iOCZS]

@XuYijie https 存在中间人攻击的问题，如果避免这种情况，他的确是安全的。中间人攻击就能看到明文了，如果明文是你说的接口加密，那仍然看不到解密后的东西，多了一层安全性。

[Sukuyedai]

你需要的是这个： https://github.com/ti-dh

流程上是 client 和 server 会通过交换公有信息后，各自分别在自己这里计算出一个用于对称加解密的 key ，这个 key 不会在网络上暴露。

但是 DH 本质上只能提升一些成本且无法根治中间人劫持问题，但是，应该足够解决你的问题。

[NickX]

难道上 HTTPS 还不够么，什么接口安全度需要用到参数的加密？除了密码不能明文外，没接触过还有什么场景要加密的。

[longlonglanguage]

“问题是前端的私钥存在哪里呢？放在代码里，本地存储里，cookie 里，都有被盗取的风险吧，难道是不存储密钥，每次调用接口都要临时生成秘钥吗？”加密是为了防止传输过程中被人窃取，担心客户端的密钥泄露，纯属多余，他自己电脑存储的密钥都被获取了，估计客户端都被人下木马了。

[ren2881971]

@renoooo 那你这是不可否认性的需求。 可以客户端本地生成密钥对，然后用私钥签名数据，公钥跟数据一起加密，作为数字信封一部分发给服务端。 服务端用他的服务器私钥先解开 数据密钥然后用数据密钥解出来数据和客户端公钥，客户端公钥验签通过后，再解密数据。 机密性、完整性、不可否认性的保护就都做了。
别问我客户端私钥怎么保护。。。。 你可以临时生成。 或者你用个 usb key 保护下？
密码保护这玩意 就是增加破解难度而已。

[soar0712]

@kuanat 貌似回复错楼层了吧

[horizon]

@NickX #26
防客户逆向

[NickX]

@horizon 具体场景说说