技术人员必须知道的手机验证码登录风险( 二 ) _验证码

增加其它验证。获取短信验证码之前必须先通过这些验证，比如图形验证码、滑动验证码、数学公式验证码等等。这些方式可以增加发送短信验证码的难度，降低人工的发送速度，尽量避免机器人自动操作。
对操作进行限流。比如现在前端常见的发送短信验证码倒计时，一般每次请求验证码后经过若干秒才能再次发送。因为如果攻击者获取到了发送验证码的服务接口，就可以摆脱前端逻辑的限制，所以后端也可以采用同样的策略，对设备Id、手机号、IP、用户、业务类型等等，以及它们的各种组合，进行频率控制。应用开发者还可以根据发送结果特征来进行控制，比如空号率，如果空号太多则说明可能是机器人随机生成的手机号。在单一频率的限制基础之上，还可以增加更多的时间控制，在分钟、小时、天等时间维度上做不同的阈值限制。
给用户提供一个短信退订入口。用户频繁收到非自己主动发起的验证码短信时，可以提供一个退订入口，让用户在短时间内关闭短信验证码，应用服务此时可以忽略给用户发送验证码的请求，或者直接去掉发送验证码的功能入口。

但是这种控制要尽量以不影响用户的正常业务操作为前提，否则就得不偿失了。

比如图形验证码的难度不要太高，毕竟大部分业务不是12306，你照搬过来可能就会弄巧成拙。
再比如对于限流控制，假设正常用户一般只在一天的某些时候进行操作，不会一天24小时都在做某一件事，则可以这样做：每个手机号每小时只能发送X次，每天只能发送Y次，这两个数值要符合 X>Y 。
对于严重的攻击，应该设置熔断机制，此时不得不牺牲可用性。比如短时间涌入了大量针对不同手机号的验证码需求，很可能是受到了DDoS攻击，因为资源有限，此时正常用户的操作也会受到影响，可以依托全局限流，触发限流时直接关闭验证码服务一段时间。

网络窃听假设用户收到了登录验证码，输入正确后提交服务端验证。在从手机端到服务端的传输过程中，会经过很多的网络设备和服务器系统，登录提交的内容有被拦截获取的可能，此时攻击者就可以阻断请求，自己拿着用户的手机号和验证码去登录。

文章插图

应对这种问题，一般需要对网络传输内容进行加密，比如现在常用的https通信，可以保证两端之间的传输内容安全，不被窃听。对于传输安全，一般这样处理也就够了。
不过https也不是银弹，如果有攻击者在客户端偷偷导入了自己的证书，然后让网络请求都先通过自己进行代理，再发送到目标地址，则攻击者还是能够获取到请求内容，想体验这种方式的可以使用fiddler试试。还有https证书存在错发的可能，如果给攻击者发放了别人的证书，此时安全传输也就没什么意义了。

文章插图

为了更高的安全性，传输内容可以在应用中加解密，客户端对要传输的数据按照与服务端的约定进行加密，然后再发送到网络，攻击者截获后，如果没有有效的解密手段，则可以保证数据不被窃听。加密的重点是保证密钥安全，不被窃取和替换，可以采用其它安全信道传输，甚至线下传递的方式。对于验证码这种仅做验证的数据，还可以通过加盐后进行慢Hash运算，攻击者即使拿到了传输内容，要进行破解的难度也相当巨大。
本地窃听如果系统上安装了恶意软件或者非官方版本的软件，特别是在盗版系统、被Root或者越狱的手机系统中，攻击者也能比较容易的拦截并窃取短信验证码；同时网络窃听中的加解密也可能失去作用，因为软件已经不可信，在不同的操作之间有没有发生什么猫腻，很难确定。
最近几年在移动设备上引入了一个称为可信执行环境（简称TEE）的概念，独立于操作系统，单独的应用，单独运行，有的甚至有单独的处理器和存储，外部很难进入和破解。一些关键的操作都封装在这里边，比如指纹的采集、注册和认证，密钥的生成和使用，版权视频的解码和显示，等等。如果把短信验证码的处理也放在这里边，无疑会安全很多，不过这要解决很多通信方面的问题，收益与成本可能不成正比。在台式机中这一技术还所见不多，可能台式机的环境已经有了比较成熟的安全体系，不过从移动端迁移过来的难度应该也不大。