共计 2501 个字符，预计需要花费 7 分钟才能阅读完成。
作者：何甜甜在吗 \
链接：https://juejin.cn/post/691615…
写在后面
在介绍具体计划之前，首先先介绍一下常见的加密算法。加密算法能够分为三大类：
- 对称加密算法
- 非对称加密算法
- 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 能够解决上述用户数据加密的问题，然而要花钱啊，老板掐指一算，还是研发人员本人去实现吧。第一次在我的项目中接触用户数据加密，可能仍有有余须要改良的中央，若有纰漏，请斧正。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
