前言：先簡(jiǎn)單介紹幾種加密

• 對(duì)稱加密
  加密解密的秘鑰是同一個(gè)。相對(duì)來講簡(jiǎn)單一些，同時(shí)相對(duì)不安全。
  常見的是：DES、AES
• 非對(duì)稱加密
  加密和解密的秘鑰不同。一般是公鑰加密，私鑰解密。
  比如客戶端需要通過jsBridge傳遞數(shù)據(jù)給h5，但是有些隱私數(shù)據(jù)如用戶的姓名 手機(jī)號(hào)等等就不能通過明文傳輸?？蛻舳送ㄟ^RSA公鑰加密后傳給h5，h5拿到后用對(duì)應(yīng)的私鑰解密后等到明文。這樣保證在傳輸過程種用戶的隱私數(shù)據(jù)不被泄露。
  常見的是：RSA、DSA
• 不可逆加密
  前面的對(duì)稱、非對(duì)稱加密都是可逆的，可以從密文得到明文。
  不可逆加密就是從一定意義上說從密文無論怎樣都得不明文。
  常見的就是：MD5、SHA
  不可逆加密的一個(gè)好處是從密文得不到明文，相同明文加密后得到的密文是一樣的。
  保存第一次加密后的密文，后面明文進(jìn)行加密后的結(jié)果如果和保存的密文不一樣，說明明文被篡改過了。

客戶端加密驗(yàn)證實(shí)際案例

• 需求
  通過微信分享出去的url，用戶點(diǎn)擊后可以在瀏覽器打開app進(jìn)入到對(duì)應(yīng)頁面。這時(shí)存在一個(gè)隱患，如果url被篡改了，本來點(diǎn)擊url是打開app進(jìn)入webview加載某一h5，變成打開webview加載登錄頁面。如果用戶在這上面進(jìn)行登錄，賬號(hào)和密碼就被盜取了。非弱加密。
• 方案
  對(duì)分享出去的url進(jìn)行加密然后驗(yàn)證。處于方便，就選擇md5進(jìn)行加密，把生成的簽名當(dāng)成額外參數(shù)放在url后面。然后用url打開app的時(shí)候同樣進(jìn)行md5校驗(yàn)，如果結(jié)果和額外參數(shù)一致則往后執(zhí)行，否則return掉。
  當(dāng)然也可以用rsa加密，公鑰放在客戶端、把私鑰放在服務(wù)端。不過每次用url打開app都要去請(qǐng)求一次服務(wù)器，好像挺麻煩也挺耗時(shí)間的，就采用了純客戶端加密。
  而且要求用非弱加密，就選擇了MD5。不然隨便和ios統(tǒng)一一個(gè)簡(jiǎn)單的算法，比如BASE64或者length*length-10啥的也可以驗(yàn)證，哈哈。
• 說說md5
  md5具體算法不清楚，但是大概知道和hash算法有關(guān)。
  java提供了MessageDigest來幫助進(jìn)行md5加密。得到的結(jié)果是長(zhǎng)度128的byte[]。這時(shí)直接log出來是亂碼的，需要轉(zhuǎn)換成16進(jìn)制的String，也就是長(zhǎng)度32位的字符串。
  網(wǎng)上說的長(zhǎng)度16位的md5其實(shí)也只是32位取的中間16位罷了，128位的二進(jìn)制怎么可能轉(zhuǎn)換成16位的16進(jìn)制字符串嘛
• 需要注意的地方
  按照上面的過程好像可以加密以及驗(yàn)證了，但是有個(gè)問題是采用的不可逆加密方法MD5是公開的，如果有“不法分子”通過大量的測(cè)試發(fā)現(xiàn)規(guī)律了：url進(jìn)行MD5然后添加在url后面。這樣就可以通過同時(shí)修改url+后面的額外參數(shù)md5值來達(dá)到篡改url的目的，而且按照客戶端的驗(yàn)證邏輯是可以通過的，因?yàn)閡rl的md5值就是和參數(shù)一樣的。
  仔細(xì)分析上面情況，發(fā)現(xiàn)完全由url（明文）進(jìn)行md5加密是有bug的。那么我們就不能讓它完全明文。在客戶端保存一段字符串，比如“ajijijj”。每次加密或者驗(yàn)證的時(shí)候都讓url加上這段擴(kuò)展字段再進(jìn)行md5加密校驗(yàn)，就可以避免上面的那種情況。
  當(dāng)然如果客戶端被去殼然后反編譯拿到了那段“ajijijj”，也是相當(dāng)于完全明文了。不過如果apk都被這樣逆向了，其他的所有都不安全了吧！