1 数据库做签名能不能防篡改？

2 能不能改完余额，趁对账没发现赶紧跑？

3 不改余额了，改一下提现不校验余额可以吗？

4 能不能从其他人的账户中转1元到自己的账户？

5 资金风险防控体系

在《论篡改微信余额的技术可刑性》一文中，鹅厂资深资金架构师分享论证了技术上的可刑性，评论区的卧龙凤雏们也纷纷提出了自己天才般的设想，场面非常热闹。

正所谓“未知攻，焉知防”，腾讯云开发者公众号特意约稿原作者，针对大家关注的技术方案做了进一步拆解研讨，看完你的余额就有救了，下半辈子就有“铁”饭碗了！

于是我觉得就还是很有必要解答一下大家的疑问和建议。

01

数据库做签名能不能防篡改？

这是网友私信的建议，签名当然是有点用的，但又不完全有用。

例如可以给（账户 ID+账户所有者+账户余额）加一个联合签名，只要数据被篡改，下一次读取验签的时候就能发现。但这一招只能防君子不能防小人，既然都决定要篡改数据了，重新计算一下签名，把签名一起改掉也不难吧？君子不会去改数据，小人弄到一个签名算法也不是难事，因此这一招意义不大。

02

能不能改完余额，趁对账没发现赶紧跑？

有朋友敏锐地观察到，对账手段都是事后的，也就是说在篡改余额和被发现之间有一个时间差，利用时间差跑路是不是就安全了？

太天真了兄dei，改完余额要想获利是不是得提现？那么在提现的时候就会遇上风控拦截。

风控是基于大数据对用户画像进行分析，特别是对巨额提现行为，如果不符合该用户日常的操作，会对这一请求进行拒绝。

那既然提现走不通，直接把钱花掉可以吗？比如花4500万买一根香蕉？同样行不通，支付的时候一样有风控，类似请求可能会被反洗钱策略拒绝。

03

不改余额了，改一下提现不校验余额可以吗？

不通过改数据，而是找到提现链路中的关键环节，绕过余额校验，能提现成功吗？

首先，改代码的难度要比改数据还要高，改代码需要经过代码审核（Code Review），还需经过自动化测试，还未把代码发布到线上就已经被发现了。

其次，前面说了提现需要过风控的，在这里同样会拦截。

最后，即便悄摸摸地把代码发布了，把余额检查和风控都绕过去，在系统上依然有防控措施。

这里除了有风控拦截，还有渠道打款的余额二次校验和其他校验，所以绕过余额检查是不可能提现成功的。

04

能不能从其他人的账户中转1元到自己的账户？

有人在评论区提到从沉睡账户中薅钱，100w个沉睡账户，每个1元也是一笔不小的收入是吧？

这当然不行！要完成转账也需要核身，就是证明你是你才可以完成转账，前台的功能走不通，只能后台改数据了。

但你觉得改数据也容易吗？

1. 怎么筛选 100w 个沉睡账户？你得先有查询权限并且知道怎么筛选出来。

2. 修改 100w 个账户的余额和流水，要改200万条数据。

3. 为了绕过账证核对，还要新增 100w 条转账记录。转账记录和账户余额可不在同一个数据库里面。

好不容易把几百万条 SQL 准备好了，准备开始执行，由于数据量过大需要分批执行，假设每秒钟修改1000条记录，修改 300w 条就需要大约50分钟。在执行期间：

• 账证明细核对可以做到分钟级，我保证技术小哥10分钟之内就会找到你；

• 在转账系统的后台监控发现，数据库的变更数远高于接口请求数，你自以为神不知鬼不觉，但在监控曲线前无处遁形；

• 因为改动数据量太大，100w 个用户中有1个人发现账户少了1元，发起了投诉，客服和技术人员通过排查发现数据被篡改。

05

资金风险防控体系

经过两轮的讨论，大家应该会发现资金风险防控从来不是点状的，而是形成一个网状结构，仅仅从单点突破，几乎都很难从这个网撕开一个口子。这也是我们资金人的职责所在：保护用户放在我们这的每一笔资金。

(来源腾讯云开发者，一手技术干货提前解锁)