短信验证码是WiFi认证系统里最常用的辅助认证手段之一，Portal认证场景下几乎绕不开它。但就是这个看似简单的东西，在实际项目中踩过的坑可能比认证协议本身还要多。短信通道选不好，成本能吃掉你好几个月的运维预算；到达率控制不好，用户投诉量能压死客服团队。

短信通道到底选哪家不是看单价那么简单

刚入行的时候我也犯过傻，拿着一堆短信服务商的报价单比单价，谁便宜选谁。结果上线第二周就出了问题：每天下午五点到七点的高峰期，短信到达率从九十几直接掉到六十多。用户填了手机号收不到验证码，反复点了好几次"重新发送"，后台一看同一个手机号十分钟内发了八条验证码，七条都没收到。

后来我才搞明白，短信通道的到达率跟几个因素关系很大：运营商（移动、联通、电信）的覆盖质量不一样，不同省份的网关资源也不一样，高峰时段的拥堵程度更是天差地别。你选的通道可能对移动用户到达率很高，但电信用户就很差。单价是便宜，但如果你有三成用户收不到验证码导致体验崩溃，这个成本省得毫无意义。

所以后来我做WiFi认证系统项目时，短信通道至少选两家互为备份，而且要求通道方提供按运营商维度的到达率报表。另外还要做一件事：在认证系统里做短信通道的自动切换逻辑。第一条短信发出去十五秒内如果用户没提交验证码，自动换备用通道再发一次。两个通道都用不同的签名和不同的码号，降低同时被拦截的概率。

验证码的安全性问题不只是防爆破

说到短信验证码的安全，大多数人想到的是防暴力破解——同一个手机号短时间内限制发送次数，同一个IP限制请求频率。这些确实是基本操作，但真正头疼的安全问题不止这些。

有一次我们做了个安全审计，发现短信验证码的发送接口被一个脚本盯上了。这个脚本不是对同一个手机号暴力破解，而是用了几百个不同的手机号，每个只请求一次验证码。因为每个手机号只发一次，频率限制根本拦不住。它这样做的目的是薅短信费用——刷我们的短信额度，然后把这些手机号卖给数据黑产。

我们后来加了两个防护措施。一个是在发送验证码之前加了一步图形验证码校验，用滑块验证的方式挡住自动脚本。另一个是引入行为分析：同一个客户端在短时间内更换手机号发送验证码，触发风控规则后要求先完成实名认证才能继续。

还有一个容易忽略的点是验证码的有效期和重发策略。有些WiFi认证系统默认的验证码有效期是五分钟，这在一个信号好的场景下没问题，但在某些信号边缘区域，用户收到验证码可能需要一两分钟，输入又要一两分钟，很容易就过期了。我们后来把有效期拉长到十分钟，但加大重试间隔——第一次重发要等六十秒，第二次要等一百二十秒。这样在体验和安全之间找了一个平衡点。

成本控制不只是选便宜的通道

短信费用的控制是个细水长流的事情。一个日均认证量在三千次的WiFi认证系统，如果每条验证码按五分钱算，一个月光是短信费用就是四千五。一年下来五万多。这个数字说大不大，但如果你能通过一些策略优化把这个费用砍掉三成甚至一半，对运营方来说就是实打实的省钱。

我们做了几个方面的优化。一个是引入了"信任设备"的概念：同一个设备在同一个地点连续认证成功三次以上，下次认证时把短信验证码换成点击确认的方式，直接省掉短信费用。另一个是对于企业内部员工这类固定用户，引导他们切换到扫码认证或者证书认证，从根本上减少对短信的依赖。还有一个容易被忽略的优化：在验证码发送接口里做去重。同一个手机号在三分钟内如果已经有未过期的验证码，直接复用原来的验证码而不是重新发一条。

这些优化做完之后，我们统计过一个项目的短信费用，相比不做优化的基线，下降了大约百分之四十五。这些钱省下来用到别的地方去，比什么都实在。