資料傳輸過程的安全考慮

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