这是一个创建于 1870 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在正在做一个小软件，主要内容是菜谱一类的。
以前做的都是个人小作品，接口都不加密的。但因为这次的内容价值比较高所以想把安全做好一点。
现在用了基本的 hmac 加密和 jwt
其实我理解这个加密根本上依赖的就是 hmac 加密用的 secret （因为只要反编译了算法就是透明的）
在小程序端做这个很简单，因为小程序有登录 api，可以在后端核实小程序的信息，然后返回 secret 和 token 给前端来加密请求。secret 是根据 token 在服务端生成的。
我打算用 react native 继续做 iOS 和 Android 客户端，这样就不能用小程序那种方法了
secret 肯定还是不能在前端存储或生成，rn 的客户端应该很容易反编译
如果从服务器获取，也想不出来可以用什么凭证，
一般大公司都怎么做呢？特殊的储存方法？还是?...想不出来了
 |
1
cxtrinityy 2019-11-12 22:36:19 +08:00 via Android
hmac 不是做完整性校验的？跟加密有什么关系
和服务端交互上 https，客户端如果不联网，不管对称还是非对称加密，解密密钥肯定存在本地，你的内容真的值得别人反编译破解那总是有缺口在那 如果客户端连网解密，密钥存服务端，AES 啥的就行 |
 |
2
bazingaterry 2019-11-12 22:47:48 +08:00
微信的 mmtls
|
 |
3
janus77 2019-11-12 22:48:48 +08:00
安全这种东西是看成本的，就算你是商业产品，只要日活太少，不防一样没事。
|
 |
4
hkitdog 2019-11-12 22:51:20 +08:00 via iPhone
参考抖音做法，自行研发一套基于 TCP 的传输协议，或者直接抄过去，抓包什么都看不到，Android 平台上，加密解密算法可以刻在内核上，最好自研，aes 这种烂大街就不要用了，经 IAT 动态调用，过程不经 Java 层，全用 C++写，在加个压缩刻基本很难逆
|
|
5
hkitdog 2019-11-12 22:52:49 +08:00 via iPhone
不想自己写的，用 360 加固吧，最低成本
|
 |
6
hadesy 2019-11-12 22:54:50 +08:00
各大加固厂商的密钥白盒了解下
|
 |
8
Foxkeh 2019-11-12 23:01:02 +08:00 via iPhone
ios 上我就留了三个
过日子，健康养生，最近加了 懒饭 你也是这一类的吗？期待你的作品。 |
 |
10
witcat OP @cxtrinityy #1 如果是需要联网的，AES 加密用的 key 也是存本地的吗？那这个 key 如果被反编译拿到是不是也可以随意伪造请求了。
其实我就是想问一下有没有和小程序里那种一样低成本的方案，目前看是无解了，可能试试第三方加密。 |
 |
11
elarity 2019-11-12 23:17:56 +08:00
看了 2-3 遍你说的，如果我感觉没错的话，你可能需要的是 dh 或者 ecdh
https://mp.weixin.qq.com/s?__biz=MzU4MjgzNzk5MA==&mid=2247483695&idx=1&sn=020fe7fc09eec49ed84c7c111be105ce&chksm=fdb372a6cac4fbb09a2152a1e71da3d18ccc68e31cad0682565d7a3af3444b05269d95ae9edc&token=1368405771&lang=zh_CN#rd 里面有 github 地址，楼主可以参考下 |
 |
12
murmur 2019-11-12 23:31:38 +08:00
风控+律师团队+native 混淆级别的签名以及加密算法
|
|
13
witcat OP @elarity #11 这个看起来不错，没有仔细看，作用是不是反爬作用更大？
我是想验证客户端真实性，找一种可以动态获取 secret 保存在内存里的方法（不在客户端存储 key ）， 我现在主要想不通的就是怎么限制用户获取 secret，因为如果不鉴权，获取 secret 的接口调用是无限制的，这样任何安全都形同虚设了 但是对于菜谱来说，不能强行要求用户登录才能看全部内容 好像还是存在本地加固 app 靠谱一点 |
 |
14
eason1874 2019-11-13 07:42:44 +08:00  2
加固讲成本，破解也讲成本，把破解成本加大到一定程度就能让人失去破解的意愿了。
数据价值特别高那就要求登录，通过 access_token 实现访问控制。数据价值一般高，那只要防抓包和防反编译就行了。防反编译可以用大厂的 APP 加固。防抓包纯粹 HTTPS 不够，可以每一个版本内置一个对称加密算法在 HTTPS 的基础上对请求进行二次签名。 比如每次请求带一个时间戳+随机字符串当 token，APP 把 token 当密钥，APP 内置 API 版本算法将请求路径和请求参数算出一个签名加入到 headers 同时发送，服务器每次收到请求先验证时间戳，超过一定时间直接拒绝，然后根据请求内容验证 token，不对也直接拒绝，这样有人抓包了也不能重放，想修改参数就必须得破解 APP 拿到加密算法。 每一个 API 版本都用不同的加密算法，要换算法直接禁 API 就行了，淘汰的 API 统一返回升级提示强迫用户升级 APP。 |
 |
15
chotow 2019-11-13 07:50:39 +08:00 via iPhone
加密见其他楼层，我这里想到的是，用错误 token 请求接口时，不要返回报错，而是错误的内容，随机返回
|
 |
16
xuanbg 2019-11-13 08:01:56 +08:00
楼主的需求是保护 API 不被盗用，这个说到底是没有万全的办法的。因为你不能确定用户来源，那么一切都只能是 open 的，也就意味着任何人都可以合法访问。
唯一有效的办法是搞个 IP 黑名单，然后监控流量，流量异常的拉黑就是了 。 |
|
17
eason1874 2019-11-13 08:09:39 +08:00
#14 补充一点。如果怕破解的人用自动工具通过 APP 一个个发送请求抓数据，那 APP 就再内置一个内容解密算法，和请求 token 转换内容密钥算法，APP 每次请求都把 token 转换成内容密钥一起传入回调处理用来解密返回的内容，服务器收到合法请求把 token 转换成内容密钥把响应内容加密返回，只返回加密内容就够了。
|
 |
19
kangzai50136 2019-11-13 10:02:30 +08:00
C++写，java 层调用？
|
Select Language