sign 签名在客户端怎么保证安全（ios，android，web）

Question

S = key + url_encode(path) + T
签名 SIGN = md5(S).to_lower()，to_lower 指将字符串转换为小写； 一般会这样签名

API接口开发时，如果考虑到接口的安全和参数不可串改，通常做法一般是吧参数通过 一定的算法签名后把签名的 sign 值一起发给服务端，这样服务端也根据除去 sign 参数，把所有参数也经过签名后，判断客服端传递的 签名是否匹配。这样就解决了，

但是有个问题，签名算法基本都一样，能做的就是签名时加上一个 key 值，但是这个key值放在客户端怎么保证安全呢。比如放在 web 端，js 代码是直接可以看得，这样肯定不安全，放在 android 上面貌似也不安全，因为 apk 是可以反编译的。

有小伙伴解决过这个问题的么？

Answer 1

我司的做法在Android中使用JNI，在c++中存储key并生成签名。在IOS中无需刻意隐藏，IOS的OC反编译难度极大。

我也想知道还有没有更加安全科学的做法

Answer 2

这个一般都会在最后加一个timestamp的时间戳，然后再加密，然后 到后台解密出来，这个时间戳和当前时间差距不超过10分钟（我们默认是10分钟，你可以设置的）则为有效，否则是无效的。

Answer 3

根本不需要搞这么麻烦，直接https就行了

如果你问题里的篡改是指中间人篡改用户的请求，用https就够了，你自己再发明一套https也不会比它更好用
如果说你是指用户自己篡改自己的请求来达到越权操作的目的，说明接口对的权限检验有问题，应该做好权限检验，而不是做个完全没用的签名，写接口时要以最大的恶意去怀疑用户的一切输入才是正确的
一般说的篡改是指前一种，后面的不叫篡改数据，叫越权攻击

---

签名通常都是指服务器端签名，就算是客户端签名也是一人一个证书，哪有把证书打包到客户端里的，那不就等于把私钥公开了
google登录密码就是明文传输，靠https就够了
点踩的朋友，不懂就多看书，别瞎J8点踩，只会显得你菜

Answer 4

api中，你不应该暴露key和加密方法到客户端，你应该采用https + 用户token的方式访问你后端接口

Answer 5

这个key好像没什么用啊

Answer 6

sign里存放的都是保密信息，比如用户的id或者其它用于验证api合法性的参数
接口的请求参数一般是不放在sign里的，直接明文传输用https加密通信过程就可以
sign是服务端加密后传给客户端存放，在请求api时带到服务端验证身份合法性的，里面不会有接口的请求信息，这两个是要分开的

Answer 7

加这些加密只能加大破解难度，没有100%的安全，哪怕你用RSA加密也是一样。防住大部分人就可以了。
你想一下，人家都能通过反编译猜测你的加密算法了，这还能是一般人？这种人一般防不住

Answer 8

对称加密的 key 放客户端肯定不好，你看几乎所有开放平台都不建议将 secret 放在 APP 端一样。

可以考虑对称加密和非对称加密结合：

1、RSA 公钥给 APP 端，私钥留在服务器端

2、APP 端提交数据时，仅在内存生成一个随机字符串，用它作为对称加密的 key 给数据加密；然后用 RSA 的公钥对 key 进行非对称加密，两个一起提交服务端

3、服务端接收到数据后，先用私钥解密得到 key，再使用 key 解密业务数据

服务端给客户端的数据同理。为啥不直接用 RSA 加密业务数据？主要是分块效率问题。

Answer 9

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

sign的主要目的是保证数据的完整性，防止在网络传输的过程中篡改数据。

name=kevin
height=170
key=$key$

假如上面的数据签名字符串是 name=kevin&height=170$$key$$ 签名结果是 c5c05d54d25791b0551b25a482d8c2e2。这个 key 在客户端是可见，别人也可以轻易拿到这个参数。
但是拿到这个key又有什么意义呢？

因为key是不会在网络中进行传输的，所以服务器最终生成签名的key还会是使用$$key$$，即使你修改了数据，也修改了客户端的key但是你没有修改掉服务器的key，最后服务器还会按照自己的方式生成sign。如果你修改了数据，最终也只是签名结果不一致而已。