sign 簽名在客戶端怎么保證安全（ios，android，web）

api中，你不應(yīng)該暴露key和加密方法到客戶端，你應(yīng)該采用https + 用戶token的方式訪問你后端接口

sign里存放的都是保密信息，比如用戶的id或者其它用于驗(yàn)證api合法性的參數(shù)
接口的請(qǐng)求參數(shù)一般是不放在sign里的，直接明文傳輸用https加密通信過程就可以
sign是服務(wù)端加密后傳給客戶端存放，在請(qǐng)求api時(shí)帶到服務(wù)端驗(yàn)證身份合法性的，里面不會(huì)有接口的請(qǐng)求信息，這兩個(gè)是要分開的

加這些加密只能加大破解難度，沒有100%的安全，哪怕你用RSA加密也是一樣。防住大部分人就可以了。
你想一下，人家都能通過反編譯猜測你的加密算法了，這還能是一般人？這種人一般防不住

對(duì)稱加密的 key 放客戶端肯定不好，你看幾乎所有開放平臺(tái)都不建議將 secret 放在 APP 端一樣。

可以考慮對(duì)稱加密和非對(duì)稱加密結(jié)合：

1、RSA 公鑰給 APP 端，私鑰留在服務(wù)器端

2、APP 端提交數(shù)據(jù)時(shí)，僅在內(nèi)存生成一個(gè)隨機(jī)字符串，用它作為對(duì)稱加密的 key 給數(shù)據(jù)加密；然后用 RSA 的公鑰對(duì) key 進(jìn)行非對(duì)稱加密，兩個(gè)一起提交服務(wù)端

3、服務(wù)端接收到數(shù)據(jù)后，先用私鑰解密得到 key，再使用 key 解密業(yè)務(wù)數(shù)據(jù)

服務(wù)端給客戶端的數(shù)據(jù)同理。為啥不直接用 RSA 加密業(yè)務(wù)數(shù)據(jù)？主要是分塊效率問題。

根本不需要搞這么麻煩，直接https就行了

如果你問題里的篡改是指中間人篡改用戶的請(qǐng)求，用https就夠了，你自己再發(fā)明一套https也不會(huì)比它更好用
如果說你是指用戶自己篡改自己的請(qǐng)求來達(dá)到越權(quán)操作的目的，說明接口對(duì)的權(quán)限檢驗(yàn)有問題，應(yīng)該做好權(quán)限檢驗(yàn)，而不是做個(gè)完全沒用的簽名，寫接口時(shí)要以最大的惡意去懷疑用戶的一切輸入才是正確的
一般說的篡改是指前一種，后面的不叫篡改數(shù)據(jù)，叫越權(quán)攻擊

這個(gè)一般都會(huì)在最后加一個(gè)timestamp的時(shí)間戳，然后再加密，然后 到后臺(tái)解密出來，這個(gè)時(shí)間戳和當(dāng)前時(shí)間差距不超過10分鐘（我們默認(rèn)是10分鐘，你可以設(shè)置的）則為有效，否則是無效的。

首先要確定sign是干什么的。

sign的主要目的是保證數(shù)據(jù)的完整性，防止在網(wǎng)絡(luò)傳輸?shù)倪^程中篡改數(shù)據(jù)。

name=kevin
height=170
key=$$key$$

假如上面的數(shù)據(jù)簽名字符串是 name=kevin&height=170$$key$$ 簽名結(jié)果是 c5c05d54d25791b0551b25a482d8c2e2。這個(gè) key 在客戶端是可見，別人也可以輕易拿到這個(gè)參數(shù)。
但是拿到這個(gè)key又有什么意義呢？

因?yàn)?code>key是不會(huì)在網(wǎng)絡(luò)中進(jìn)行傳輸?shù)?，所以服?wù)器最終生成簽名的key還會(huì)是使用$$key$$，即使你修改了數(shù)據(jù)，也修改了客戶端的key但是你沒有修改掉服務(wù)器的key，最后服務(wù)器還會(huì)按照自己的方式生成sign。如果你修改了數(shù)據(jù)，最終也只是簽名結(jié)果不一致而已。