數據傳輸過程的安全考慮

1. 數據包啓用Gip壓縮(服務端下行)，節省流量，通常瀏覽器或httplib支持decode.

 

2. AES加密解密 

 加密和解密使用同一個key, 雙方都保留此key，準確的說須要key和vector(向量)

 

3. RSA

加密時用public key加密, 解密時用private key解密，密鑰是成對的，這樣加密方只須要對方的公鑰加密，私鑰在解密方這裏(甲乙雙方反過來同樣看待)，安全。密鑰不可能同時存在一方。

key有1024或2048位，即使同一內容，兩次加密結果可能不一樣，但不影響解密。 

 

original: c360.pay

aes: vbPaUC/FGy5m4rQ4HO5JUg==

rsa: tsrks2u9Nf5EgA0akKCPj5YK/h9R7lldPyOipozk/XlCpnjhRcjPeSeZfCrIR1WPaMfSRsjanqrmoA5PuTE92cUi1cAx6+UjsVr2BBZKVmIhl2uoLSuIIIDIxp+kAOQ0DYLFHW4QgHlwSjqJjDAeu55ASuXx5D/MjZy3zKOXWqc=

 

可見AES加密的內容比RSA小不少，但RSA應該更安全些。

 

4. API接口安全

要有驗證，不能直接訪問。

cookie或auth sig , 在head增長此參數，根據必定的規則生成，服務端驗證，確保這個請求是合法的

 

**參數加簽名** 

全部請求必需有appkey和timestamp 

appkey和appsecret是對應一組(由服務端生成)，傳輸過程當中使用appkey(服務端根據此識別客戶端並找出appsecret值)，簽名時使用appsecret作hash。

時間戳由客戶端帶上來，服務端驗證若是時差太大剛認爲請求無效(重複請求或數據被篡改)

 

舉例：

/api/resource?para1=xxx&para2=xxx

生成簽名: hash(para1=xxx&para2=xxx&appkey=xxx&timestamp=148897123456)=fx51lkd8vjkxsksdlk  

注：生成簽名的規則及內容本身根據實際狀況決定

最終客戶端發起的請求以下：

/api/resource?para1=xxx&para2=xxx&appkey=xxx&timestamp=148897123456&sign=fx51lkd8vjkxsksdlk  

服務端收到後檢驗

a. 檢查timestamp值是否合理，若是差值太大，直接response error

b. 根據appkey找到appsecret，和客戶端同樣的邏輯作hash, 獲得的簽名和sign參數比較， 如不相等直接response error