過去一段時間負責了項目中的用戶管理模塊，為了保證用戶數(shù)據(jù)安全，該模塊涉及了用戶數(shù)據(jù)加密
寫在前面
在介紹具體方案之前，首先先介紹一下常加見的加密算法。加密算法可以分為三大類：
- 對稱加密算法
- 非對稱加密算法
- Hash算法
對稱加密算法
加密和解密使用相同的密鑰。對稱加密算法加密解密速度快，但安全性較差
常見的對稱加密算法：DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6和AES
非對稱加密算法
加密和解密使用不同的密鑰，也稱為公私鑰加密。非對稱加密的缺點是加解密速度要遠遠慢于對稱加密，在某些極端情況下，甚至能比非對稱加密慢上1000倍。但安全性比對稱加密算法高
常見的非對稱加密算法：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數(shù)字簽名用）
Hash算法
Hash算法特別的地方在于它是一種單向算法，用戶可以通過Hash算法對目標信息生成一段特定長度的唯一的Hash值，卻不能通過這個Hash值重新獲得目標信息。Hash算法常用在不可還原的密碼存儲、信息完整性校驗等
常見的Hash算法：MD2、MD4、MD5、HAVAL、SHA、SHA-1、HMAC、HMAC-MD5、HMAC-SHA1
用戶管理模塊中需要進行加密的地方
用戶管理模塊中但凡涉及密碼的地方都需要進行加密處理
admin賬戶激活
平臺默認包含一個admin賬號，admin賬號在初次使用時都需要激活密碼，調(diào)用激活接口時前端傳輸給后端的密碼需要進行加密用戶登陸
激活完成后，admin賬號才可以進行登陸，調(diào)用登陸接口時，如果不對密碼進行加密明文傳輸會被不法分子利用，導致數(shù)據(jù)泄露等安全問題用戶創(chuàng)建
admin賬號創(chuàng)建普通用戶時需要需要給普通用戶設置初始密碼，因此調(diào)用用戶創(chuàng)建接口時前端傳輸給后端的數(shù)據(jù)需要進行加密處理用戶信息修改
用戶信息修改時可以修改密碼，因此調(diào)用修改用戶信息接口時前端將數(shù)據(jù)傳輸給后端時需要進行加密處理數(shù)據(jù)入庫
admin賬號創(chuàng)建普通用戶時會給普通用戶設置初始密碼，這部分數(shù)據(jù)都是保存在數(shù)據(jù)庫中的，admin賬戶激活時的密碼也是保存在數(shù)據(jù)庫中。數(shù)據(jù)庫并不是保險箱，也存在被攻擊的可能性，導致用戶數(shù)據(jù)被盜，因此對入庫的數(shù)據(jù)中安全級別較高的字段進行加密處理。很明顯用戶的密碼是需要進行加密后在入庫的
如何選擇加密算法實現(xiàn)加密功能
-
admin賬號激活
admin賬戶必須對密碼進行解密所以只可以在對稱加密和非對稱加密算法。因此admin賬號激活采用RSA加密算法和AES128加密算法，由Web端管理公鑰和私鑰，具體步驟如下：- web端發(fā)送base64編碼后的RSA加密算法生成的公鑰
- server端base64解碼公鑰
- server端隨機生成一個16位的隨機字符串
- server端使用公鑰對生成的隨機字符串進行加密
- server端將加密后的隨機字符串在進行base64編碼并發(fā)送給web端
- web端base64解碼隨機字符串
- web端對base64解碼后的字符串在使用私鑰解碼
- web端將密碼拼接為新的字符串，新的字符串為隨機字符串+密碼
- web端將隨機字符串作為AES加密算法的密碼對密碼進行加密發(fā)送給server端
- server端使用隨機字符串對新的字符串進行解密
- server端系解析解密后的字符串，校驗隨機字符串是否一致
- server端解析出字符串中的密碼并對密碼進行加密入庫
說明：數(shù)據(jù)入庫加密的密鑰和對隨機字符串加密的密鑰不相同
時序圖如下：
是不是覺得過程有點過于復雜，由server端管理公鑰和私鑰，web端獲取公鑰并對密碼加密發(fā)送給server端，server端在使用私鑰解密密碼這樣也沒毛病啊
小心中間人攻擊
什么是中間人攻擊，中間人攻擊(Man-in-the-MiddleAttack，簡稱“MITM攻擊”)是指攻擊者與通訊的兩端分別創(chuàng)建獨立的聯(lián)系，并交換其所收到的數(shù)據(jù)，使通訊的兩端認為他們正在通過一個私密的連接與對方 直接對話，但事實上整個會話都被攻擊者完全控制。在中間人攻 擊中，攻擊者可以攔截通訊雙方的通話并插入新的內(nèi)容。中間人攻擊是一個(缺乏)相互認證的攻擊。大多數(shù)的加密協(xié)議都專門加入了一些特殊的認證方法以阻止中間人攻擊。例如，SSL協(xié)議可以驗證參與通訊的一方或雙方使用的證書是否是由權威的受信 任的數(shù)字證書認證機構頒發(fā)，并且能執(zhí)行雙向身份認證
中間人攻擊過程如下：
- 客戶端發(fā)送請求到服務端，請求被中間人截獲
- 服務器向客戶端發(fā)送公鑰
- 中間人截獲公鑰，保留在自己手上。然后自己生成一個【偽造的】公鑰發(fā)給客戶端
- 客戶端收到偽造的公鑰后，生成加密hash值發(fā)給服務器
- 中間人獲得加密hash值，用自己的私鑰解密獲得真秘鑰。同時生成假的加密hash值，發(fā)給服務器
- 服務器用私鑰解密獲得假密鑰。然后加密數(shù)據(jù)傳輸給客戶端
如果直接發(fā)送公鑰給web端就很容易被中間人攻擊，導致數(shù)據(jù)泄露
-
用戶登陸
用戶登陸對密碼進行校驗是可以不需要進行解密的，因此用戶登陸選擇的是Hash算法中的MD5加密算法，雖然MD5是可以破解的，但是為了能夠和其他部門進行對接只能選擇MD5加密算法，具體步驟如下：- 前端MD5加密密碼
- 服務端查詢指定用戶的密碼
- 將數(shù)據(jù)庫查詢到的密碼用私鑰進行解密
- 將解密后的密碼進行MD5加密和前端傳入的密碼進行比對
時序圖如下：
-
用戶創(chuàng)建&用戶信息修改
使用AES128加密算法，和激活使用同相同的公鑰 -
數(shù)據(jù)入庫
使用AES128加密算法，和激活所使用的公鑰不為同一個
說明：上述流程省略了部分業(yè)務邏輯，如密碼格式校驗等，本文主要介紹的是加密解密要抓關鍵了
小結(jié)
用 HTTPS可以解決上述用戶數(shù)據(jù)加密的問題，但是要花錢啊，老板掐指一算，還是研發(fā)人員自己去實現(xiàn)吧。第一次在項目中接觸用戶數(shù)據(jù)加密，可能仍有不足需要改進的地方，若有紕漏，請指正
大半年不寫文章，感覺文筆都生疏了不少，給點贊支持一下呀
