前言：先簡單介紹幾種加密
- 對稱加密
加密解密的秘鑰是同一個。相對來講簡單一些疑俭，同時相對不安全篙议。
常見的是：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值來達(dá)到篡改url的目的祝谚，而且按照客戶端的驗證邏輯是可以通過的宪迟，因為url的md5值就是和參數(shù)一樣的。
仔細(xì)分析上面情況交惯，發(fā)現(xiàn)完全由url（明文）進行md5加密是有bug的次泽。那么我們就不能讓它完全明文。在客戶端保存一段字符串席爽，比如“ajijijj”意荤。每次加密或者驗證的時候都讓url加上這段擴展字段再進行md5加密校驗，就可以避免上面的那種情況只锻。
當(dāng)然如果客戶端被去殼然后反編譯拿到了那段“ajijijj”玖像，也是相當(dāng)于完全明文了。不過如果apk都被這樣逆向了齐饮，其他的所有都不安全了吧捐寥！
