数据传输过程的安全考虑

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