短信防刷策略？

[Markxu0]

公司前些时间短信被恶意刷了，然后让我想个短信防刷的策略。

目前我想到的方案主要如下：

• 1：限制同设备，同 IP，同手机号的发送次数和频率。
• 2：请求 IP 和手机号国家码一致性校验。请求 IP 不在手机号所属国家 /区域，则前置人机验证（图片验证码）
• 3：高风险地区 /ip，前置人机验证

主要业务在 C 端，最好能够减少图片验证码出现的次数，提升用户体验。 上面的方案就算是抛砖引玉了，想请教一下大家有没有其他更好的方案。

[stiekel]

再加个人机滑动验证。

[delectate]

其实还可以加个验证，比如某时刻（ 10:00~11:00 ），服务端限制每个 ip 只能发送 x 条短信，某个手机号、id 只能发送 x 条短信（阈值设定的高一点，比正常值高 5%），超过的请求，符合严苛验证条件的通过，否则一律阻拦。阻拦的 ip 超过某阈值自动封禁；可以有效应对攻击、滥用。

[xcstream]

滑动验证码

[firstfan]

直接集成第三方的人机验证，你说的策略人家都有，就是 IP，设备检查，然后检查后觉得有风险再出滑动验证之类的

[crab]

同号码限制次数，IP，验证码。

[312ybj]

短信服务器应该有防轰炸策略。本地系统也可以维护一套防轰炸策略

[opengps]

少了一个关键止损措施，避免大量伪造突破限制的方案，那就是每小时短信发送量。
这样的好处是始终有个约束，即使黑客选了你应用漏洞用于攻击或者推广，也效果收到制约，负面效果是，每次有突发大型活动要注意提前调高约束范围

[leaves7i]

学习 tg，上次我登录前两次等了几分钟都没收到验证码，我再让它重发它就直接报代码了，让我一天后再重试……

[wangbenjun5]

最有效的应该是验证码了，但是验证码加多了还影响用户体验，最简单的是对接一个第三方验证码服务，有些是基于大数据风控规则判断用户的风险级别，适时的弹出验证码，挺好，就是费钱，自己弄还很麻烦。

[dcsite]

@opengps 似乎有的平台可以设定这个阀值，可以设定 10 分钟、半小时、一小时、一天总发送量

[igeeky]

1. 人机验证, 简单,粗暴,有效.
2. 接口添加签名. 只有破解了签名算法, 才能发出合法的请求及签名数据. 对于移动端 Java 的 APP 应用 /WEB JS 应用, 破解难度倒也不是很高, 但是比没有签名的安全性还是要高一个数量级.
3. 基于 IP,客户端标识的安全控制. 基本没什么用, 花几块钱一个小时的 IP 代理库你就跪了.

[x86]

稍微好点的平台短信网关都有这个吧

[Lemeng]

加个验证码，是最方便有效的

[igeeky]

@x86
@312ybj 短信平台一般只有针对某一个手机号的频率限制.
恶意刷短信的人, 不会使用同一个号码, 也不会使用同一个 IP,或者同一个客户端标识.
另外短信平台,巴不得有人天天刷短信了, 这对他们是有好处的.

[tutugreen]

题外话，实在拦不住，比如限制一段时间量，超出了让用户上行发送短信（降低体验
或者接入运营商一键认证那种（需要手机+3/4/5G 网络

[docx]

比如某宝的短信，是账号一天有下发总量，超过之后变成语音，或者不再允许获取。
以前测试的，现在可能改了。

[linksNoFound]

某 IP 验证码超过 3 次未验证就拉黑

[ogli]

应该加强验证码参数校验加密，和 app 反抓包，破解等等。人机验证这样的在多少次后刷出，其实不能完全应付，别人都是打一枪换一地。很被动。

[zpfhbyx]

api 动态加密啊 加签名 然后解密失败限制，一般增加难度，都不会再搞你

[zpfhbyx]

还有一个前置校验，前一个 api 的请求和当前 api 的请求来源一致，包括但是不限于 ip ua 其他的一些固定值