前言

产品设计中不可避免的会需要考虑各种防刷&防作弊等安全策略设计，今天就简单总结一下相关方法。

为什么要考虑这些

作为一个产品狗，设计产品是为了给用户提供优质的服务，如果被刷被作弊就会间接影响到产品服务的质量。比如一个短信接口被刷爆导致公司需要支付巨额短信服务费，进一步影响公司状况从而无法继续为正常用户提供服务等等。

随便说点

1. 姓名身份证匹配认证

最近一个项目接触到有关姓名与身份证匹配的认证，这样的第三方接口相对价格较高，所以被刷的损失也就较大。
对此，我设计的策略是：

1. 单个注册用户，每天最多认证x次，x次失败后当天（24点为界）无法继续认证
2. 单个注册用户，最多累计认证y次，超过则无法再认证
3. 对所有用户，客服可以再后台进行认证

以上策略设置了单个用户一天可认证的上限和累计可认证上限，然后在后台为用户保留最极端情况（就是用户真就不知道啥原因又不是有意的认证失败y次）的处理方式——联系客服（机器没法处理的事，还是得交给人来处理）

但是简单得一条“单个注册用户每天最多认证3次”的策略，却不是你和技术说“单个注册用户每天认证x次后，页面认证按钮置灰不可点”这么简单的。要知道前端的控制是可以被轻易修改的，而且在认证的时候POST or GET了哪些接口在如今各种浏览器的F12里都是可以被小白如我的人找到并利用。因此：

涉及到限制策略，就需要前端+接口一起限制

所以上面的“单个注册用户每天最多认证x次”，就需要说明不仅是“用户认证失败x次后，当天24点前页面认证按钮置灰不可点”，还包括“后端提供的调用第三方认证服务的接口，需要根据输入的用户名判断，若当天已经被调用达到x次则接口直接返回错误”。

2. App的防刷&防作弊

最近还向组内产品大牛Mr.D讨教了一些App相关的防刷&防作弊策略。
App因为其可以获取更多的信息，便可以做的更多：

1：前端+接口限制，一般的登录后操作可以通过用户名等标识进行次数判断限制
2：登录前操作可以通过获取相关设备ID来进行次数判断限制

最后

通过互联网这张大网提供服务，用户都藏在背后，天然就减低了做坏事的成本。我们希望给用户做无罪假设，但是不可避免的还是要考虑各种有罪假设情况下的应对措施。总的来说：用户没有错，只要服务有问题了，就是产品狗的错，即使是被刷爆了那也是产品狗没考虑周全没做好应对策略（当然大黑客来攻击就没辙了），就酱。