前言：先簡單介紹幾種加密

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

客戶端加密驗證實際案例

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