过来一段时间负责了我的项目中的用户治理模块，为了保障用户数据安全，该模块波及了用户数据加密

写在后面

在介绍具体计划之前，首先先介绍一下常加见的加密算法。加密算法能够分为三大类：

  • 对称加密算法
  • 非对称加密算法
  • Hash算法

对称加密算法
加密和解密应用雷同的密钥。对称加密算法加密解密速度快，但安全性较差
常见的对称加密算法：DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6和AES

非对称加密算法
加密和解密应用不同的密钥，也称为公私钥加密。非对称加密的毛病是加解密速度要远远慢于对称加密，在某些极其状况下，甚至能比非对称加密慢上1000倍。但安全性比对称加密算法高
常见的非对称加密算法：RSA、ECC（挪动设施用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

Hash算法
Hash算法特地的中央在于它是一种单向算法，用户能够通过Hash算法对指标信息生成一段特定长度的惟一的Hash值，却不能通过这个Hash值从新取得指标信息。Hash算法罕用在不可还原的明码存储、信息完整性校验等
常见的Hash算法：MD2、MD4、MD5、HAVAL、SHA、SHA-1、HMAC、HMAC-MD5、HMAC-SHA1

用户治理模块中须要进行加密的中央

用户治理模块中凡是波及明码的中央都须要进行加密解决

  • admin账户激活

平台默认蕴含一个admin账号，admin账号在首次应用时都须要激活明码，调用激活接口时前端传输给后端的明码须要进行加密

  • 用户登陆

激活实现后，admin账号才能够进行登陆，调用登陆接口时，如果不对明码进行加密明文传输会被不法分子利用，导致数据泄露等平安问题

  • 用户创立

admin账号创立普通用户时须要须要给普通用户设置初始密码，因而调用用户创立接口时前端传输给后端的数据须要进行加密解决

  • 用户信息批改

用户信息批改时能够批改明码，因而调用批改用户信息接口时前端将数据传输给后端时须要进行加密解决

  • 数据入库

admin账号创立普通用户时会给普通用户设置初始密码，这部分数据都是保留在数据库中的，admin账户激活时的明码也是保留在数据库中。数据库并不是保险箱，也存在被攻打的可能性，导致用户数据被盗，因而对入库的数据中安全级别较高的字段进行加密解决。很显著用户的明码是须要进行加密后在入库的

如何抉择加密算法实现加密性能

  • admin账号激活

admin账户必须对明码进行解密所以只能够在对称加密和非对称加密算法。因而admin账号激活采纳RSA加密算法和AES128加密算法，由Web端治理公钥和私钥，具体步骤如下：

  • web端发送base64编码后的RSA加密算法生成的公钥
  • server端base64解码公钥
  • server端随机生成一个16位的随机字符串
  • server端应用公钥对生成的随机字符串进行加密
  • server端将加密后的随机字符串在进行base64编码并发送给web端
  • web端base64解码随机字符串
  • web端对base64解码后的字符串在应用私钥解码
  • web端将明码拼接为新的字符串，新的字符串为随机字符串+明码
  • web端将随机字符串作为AES加密算法的明码对明码进行加密发送给server端
  • server端应用随机字符串对新的字符串进行解密
  • server端系解析解密后的字符串，校验随机字符串是否统一
  • server端解析出字符串中的明码并对明码进行加密入库

阐明：数据入库加密的密钥和对随机字符串加密的密钥不雷同
时序图如下：

是不是感觉过程有点过于简单，由server端治理公钥和私钥，web端获取公钥并对明码加密发送给server端，server端在应用私钥解密明码这样也没故障啊

小心中间人攻打
什么是中间人攻打，中间人攻打(Man-in-the-MiddleAttack，简称“MITM攻打”)是指攻击者与通信的两端别离创立独立的分割，并替换其所收到的数据，使通信的两端认为他们正在通过一个私密的连贯与对方 直接对话，但事实上整个会话都被攻击者齐全管制。在中间人攻 击中，攻击者能够拦挡通信单方的通话并插入新的内容。中间人攻打是一个(不足)互相认证的攻打。大多数的加密协议都专门退出了一些非凡的认证办法以阻止中间人攻打。例如，SSL协定能够验证参加通信的一方或单方应用的证书是否是由权威的受信 任的数字证书认证机构颁发，并且能执行双向身份认证
中间人攻打过程如下：

  • 客户端发送申请到服务端，申请被中间人截获
  • 服务器向客户端发送公钥
  • 中间人截获公钥，保留在本人手上。而后本人生成一个【伪造的】公钥发给客户端
  • 客户端收到伪造的公钥后，生成加密hash值发给服务器
  • 中间人取得加密hash值，用本人的私钥解密取得真秘钥。同时生成假的加密hash值，发给服务器
  • 服务器用私钥解密取得假密钥。而后加密数据传输给客户端

如果间接发送公钥给web端就很容易被中间人攻打，导致数据泄露

  • 用户登陆

用户登陆对明码进行校验是能够不须要进行解密的，因而用户登陆抉择的是Hash算法中的MD5加密算法，尽管MD5是能够破解的，然而为了可能和其余部门进行对接只能抉择MD5加密算法，具体步骤如下：

  • 前端MD5加密明码
  • 服务端查问指定用户的明码
  • 将数据库查问到的明码用私钥进行解密
  • 将解密后的明码进行MD5加密和前端传入的明码进行比对

时序图如下：

  • 用户创立&用户信息批改

应用AES128加密算法，和激活应用同雷同的公钥

  • 数据入库

应用AES128加密算法，和激活所应用的公钥不为同一个

阐明：上述流程省略了局部业务逻辑，如明码格局校验等，本文次要介绍的是加密解密要抓要害了

小结

用 HTTPS能够解决上述用户数据加密的问题，然而要花钱啊，老板掐指一算，还是研发人员本人去实现吧。第一次在我的项目中接触用户数据加密，可能仍有有余须要改良的中央，若有纰漏，请斧正
大半年不写文章，感觉文笔都陌生了不少，给点赞反对一下呀