数据交互加密

没有绝对的安全!
        这段时间发现有人在恶意攻击我们的接口,通过篡改接口数据,绕过前端校验直接请求后台接口。所以我们想要对重要接口的数据交互进行加密处理。这里只能使用可逆的加密方式,其中大体可分对称加密,非对称加密。但是不管是对称加密还是非对称加密都存在秘钥的问题,秘钥如何生成、如何存储。
        据我所知我们当前的技术还无法做到让秘钥在网络安全传输。为什么这么说呢?其实很容易理解,想要在网络上安全传输秘钥,就要对秘钥进行加密,但是加密也需要秘钥,又怎么保证加密秘钥的安全呢?这是个死循环,至少目前无解!
        所以我们在认清这个事实的前提下所说的数据交互加密,只是尽可能的隐藏真实数据,增加恶意破解的成本。
网上给出的关于数据加密的方案很多都是采用对称加密和非对称加密结合的方式。

  • 首先由服务端采用非对称加密方式,生成公钥spub、私钥spri
  • 然后将公钥spub传递给客户端
  • 客户端启动时也采用非对称加密方式生成公钥cpub、私钥对cpri
  • 然后客户端将cpub通过spub进行加密传递给服务端
  • 服务端根据spri对密文解密,从而得到cpub
  • 服务端生成随机key,通过cpub加密传递给客户端,客户端通过cpri对密文解密,从而得到随机key
  • 客户端通过对称加密算法,使用随机key值进行加密,然后传递给服务端
  • 服务端通过随机key对密文进行解密,从而得到真正提交的数据

        网上有很多详细的过程说明,我这里只是大概讲述一下,通过上面过程的解读,大家可以发现其实这套加密方式也并不是安全的,因为服务端无法识别用户是否是恶意用户,即使有这套加密,恶意用户还是可能获取到随机key,然后随意篡改参数去请求接口,只是这样做的技术含量比直接篡改明文要难一些,增加了攻击成本。所以数据交互加密只能降低数据被篡改的概率,但是无法完全避免数据被篡改,因此这就要求我们后端开发人员要结合具体的业务逻辑去做相应的校验,不能一味的相信前端传递的接口参数。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值