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¶2=xxx
生成签名: hash(para1=xxx¶2=xxx&appkey=xxx×tamp=148897123456)=fx51lkd8vjkxsksdlk
注：生成签名的规则及内容自己根据实际情况决定
最终客户端发起的请求如下：
/api/resource?para1=xxx¶2=xxx&appkey=xxx×tamp=148897123456&sign=fx51lkd8vjkxsksdlk
服务端收到后检验
a. 检查timestamp值是否合理，如果差值太大，直接response error
b. 根据appkey找到appsecret，和客户端一样的逻辑做hash, 得到的签名和sign参数比较， 如不相等直接response error
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。