用户管理模块：如何保证用户数据安全

过去一段时间负责了项目中的用户管理模块，为了保证用户数据安全，该模块涉及了用户数据加密

写在前面

在介绍具体方案之前，首先先介绍一下常加见的加密算法。加密算法可以分为三大类：

• 对称加密算法
• 非对称加密算法
• 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可以解决上述用户数据加密的问题，但是要花钱啊，老板掐指一算，还是研发人员自己去实现吧。第一次在项目中接触用户数据加密，可能仍有不足需要改进的地方，若有纰漏，请指正
大半年不写文章，感觉文笔都生疏了不少，给点赞支持一下呀