app介面安全性設計淺析
之前面試的時候被問到這個，app介面安全性，這個因不同的場景，要考慮的情況也不一樣。下面把自己的見聞和思考寫一下吧。
sign=MD5(userId+timestamp+randomString)
timestamp 一般用來給伺服器驗證請求時間區間，5-30分鐘不等。
randomString 作為簽名的引數作用不大。
這個由於都是明文的，一般都能猜到這麼簽名。所以，會加一個鹽，
sign=MD5(userId+timestamp+randomString+salt1)
salt1為客戶端與服務端保留，是個常量。一般不在介面中傳遞。
有人說，將app放進模擬器或者反編譯，就能獲得salt1。
所以，光是一個常量是不夠的，還要一個動態量。這個動態量就是token，一般在每次使用者登入後，會獲得一個重新整理的token，UUID生成的。
sign=MD5(userId+timestamp+randomString+salt1+token)
token的有效期一般為12小時或24小時。
這樣，客戶端的請求，服務端先驗證token，再驗證sign。
以上的處理，效果如下：
- 較長時間段前的請求連結無效；
- 不良使用者把篡改的請求連結在瀏覽器中操作無效；
- 每隔一段時間，有一個登入的驗證。
但以上也看出，token驗證的難度並不大，畢竟token的有效時間有十幾個小時。
因此，本人設計添加了一個動態量，叫token2。
這個token2的有效期更短，一般在幾十秒，假定30秒-45秒。也可以更短。
它由token1和salt1生成，不在客戶端保留，每次介面請求都要從伺服器拿。獲取token2中也會用到AES加密。
然後把token2也放到sign簽名中（介面中不傳）：
sign=MD5(userId+timestamp+randomString+salt1+token+token2)
服務端原來驗證token改為驗證token2了，這樣，如果不是極端情況，保證了2點：
- 客戶端的請求都是由APP端發出的；
- 每次請求的有效期只有30-45秒。
設定30-45秒是考慮到wap端的使用者請求，點選，瀏覽的平均時間會稍微比app端慢一些。如果在一個網頁，使用者遲疑了一下再點選，發現連結失效，需要重新退回上個頁面，不是太好，所以設定幾十秒。
還有RSA也能簽名。
當然，除了MD5，還有AES加密。AES也有加salt加密。由於是對稱型，AES可以多次加密。可是隻要salt知道，也能容易猜到，本人一般配合MD5使用。
（2）https
這個是要證書的，要錢的。本人還沒做過。
（3）第三方授權。
大公司用的多，獲取騰訊，新浪使用者資訊用這種方式。其中關鍵，是一個code和token，也是動態的，安全性，比以上介紹的要強一些。