背景

某天夜里，你正睡着觉，与周公神游。

老板打来电话：“小李，快看一下，系统出故障了，一个小时发了200条短信，再搞下去，我要破产了..."

巴拉巴拉...

于是，你赶紧跳下床，查了一个后台日志，发送短信API接口5s发送一次，都已经发送了500条了。在达到每日限额后，自动终止了。很明显被黑客攻击了。

500 * 0.1 * 8 = 400

一晚上约干掉了400元人民币

睡意全无，赶紧起来排查原因

故障分析

我司是做国外业务的，用的短信厂家是RingRing, 没有阿里云那种自带的强悍的预警和封禁功能。黑客通过伪造IP地址和手机号然后攻破了APP的短信接口，然后顺藤摸瓜的拿到相关发布的全部应用。于是，一个晚上，单个APP的每日短信限额和全部短信限额都攻破了。

APP使用的是https双向加密，黑客也不是单纯的爆破，没有大量的验证码错误日志。我们现在都不清楚黑客是通过什么方式绕过我们系统的，或者直接攻破了验证码

可能有懂这方面的掘友，可以分享一下哈

我们先上了一个临时方案，如果10分钟内，发送短信超过30条，且手机号超过60%都是同一个国家，我们关闭短信发送功能10分钟，并推送告警

然后抓紧时间去升级验证码，提高安全标准

验证码

文字验证码

我司最开始用的就是这种，简单易用。但是任你把噪点和线条铺满，整的面目全非，都防不住机器的识别，这种验证码直接pass了

优点：简易，具有一定的防爆破功能

缺点：防君子不防小人，在黑客面前，GG

滑块验证码

我司对于滑块验证码有几点考虑：

基于这几点考虑，我司放弃了这个方案。但平心而论，国内用滑块验证码的是最多的，原因如下：

npm install rc-slider-captcha

import SliderCaptcha from 'rc-slider-captcha';

const Demo = () => {
return (

    <SliderCaptcha

      request={async () => {
return {

          bgUrl: 'background image url',

          puzzleUrl: 'puzzle image url'

        };

      }}

      onVerify={async (data) => {

        console.log(data);
// verify data
return Promise.resolve();

      }}

    />

  );

};

滑块验证码是用的最多的验证码，操作简单，基本平替了图片验证码

图形顺序验证码 & 图形匹配验证码 & 语顺验证码

我司没有采用这种方案的原因如下：

总结：

安全性更强，用户量越大的网站越受青睐

难度相对更大，频繁验证会流失一些用户

reCAPTCHA v3

综上，我司使用了reCAPTCHA

理由如下：

<script src="https://www.google.com/recaptcha/api.js?render=reCAPTCHA_site_key"></script>

<script>
function onClick(e) {

    e.preventDefault();

    grecaptcha.ready(function() {

      grecaptcha.execute('reCAPTCHA_site_key', {action: 'submit'}).then(function(token) {
// Add your logic to submit to your backend server here.

      });

    });

  }
</script>

// 返回值

{
score: 1  // 评分0 到 1。1：确认为人类，0：确认为机器人。
hostname: "localhost"  
success: true,
challenge_ts: "2024-xx-xTxx:xx:xxZ"
action: "homepage"

}

紧急上线后，安全性大大增强，再也没有遭受黑客袭击了。本以为可以睡个安稳觉了，又有其他的问题了，听我细讲

根据官方文档，建议score取0.5, 我们根据测试的情况，降低了标准，设置为0.3。上线后，很多用户投诉安全度过低，请30分后重试。由于我们当时的业务是出行和游乐, APP受限后，用户生活受到了很大限制，很多用户预约了我们的产品，却用不了，导致收到了大量的投诉。更糟糕的时候，我们的评分标准0.3是写死的，只能重新发布，一来二去，3天过去了。客服被用户骂了后，天天来我们技术部骂我们。哎，想想都是泪

我们紧急发布了一版，将评分标准设置成可配置的，通过API获取, 暂定0.1。算是勉强度过了这一关

reCAPTCHA v2

把分数调整到0.1后，我们觉得不是很安全，有爆破的风险，于是在下个版本使用了v2

使用v2，一切相对平稳，APP短信验证码风波也算平安度过了

2FA

双因素验证(Two-factor authentication,简称2FA，又名二步验证、双重验证)，是保证账户安全的一道有效防线。在登录或进行敏感操作时，需要输入验证器上的动态密码（类似于银行U盾），进一步保护您的帐户免受潜在攻击者的攻击。双因素验证的动态密码生成器分为软件和硬件两种，最常用的软件有OTP Auth和谷歌验证器 (Google Authenticator)

经市场调用，客户要求，后续的APP，我们的都采用2fa方案，一人一码，安全可靠。

实现起来也比较简单，后端使用sha1加密一串密钥，生成哈希值，用户扫码绑定，然后每次将这个验证码提交给服务器进行比对即可

每次使用都要看一下验证码，感觉有点烦

服务器和手机进行绑定，是同一把密钥，每次输入都找半天。一旦用户更换手机，就必须生成全新的密钥。

总结

参考资料