OTP 的送达与风险：验证码到底证明了什么

OTP 证明什么

OTP 只回答一个问题：此刻坐在您面前的人，能不能在这个号码上收到短信？用于找回账号和登录，这个答案有用，因为它把会话绑在用户能控制的东西上。它不是身份证件。号码可能被回收、被换到新 SIM 卡、被呼转，也可能被同住的另一个人看到。

设计时要分清这一点。低价值操作，一个 OTP 就够了。涉及转账、改密码或新增收款人，就要再加一道检查：延迟一段时间、在已有会话里二次确认、回拨已知渠道，或者人工复核。验证码只是一个因素，不是整个决定。

验证码从哪里漏出去

SIM 卡补换会把号码换到一张新卡上。攻击者让营业厅或客服相信自己是机主，下一条验证码就进了新卡。号码回收不需要攻击者也能造成同样的结果。运营商把一个停用号码重新放号，新机主收到的是给旧账号的验证码。两种情况都说明，要查号码最近有没有携转或重新分配。

呼转和语音信箱转文字会把短信送到另一个收件箱。钓鱼直接复制表单，把验证码收走，网络根本看不到攻击。网络路径上的拦截更少见，也不在应用的控制范围内。实际应对是加第二个因素，而不是把验证码做长。定义见 OTP 词条。

有用的控制

同一个号码、同一个 IP 和同一台设备请求验证码，都要限制频率。有效期要短，一个验证码只能用一次，并把它绑定到发起请求的会话。发送方要注册，内容要克制。看起来像营销的验证码可能被过滤，被过滤的验证码只会变成客服工单，不会变成登录。

信任号码之前先检查它。收不到短信的号码、刚携转的号码、频繁重置的号码，都值得多一道步骤。高价值操作要求已有会话或第二个渠道。把请求、提交、回执和输入验证码记成独立事件，才能分清是送达问题还是用户问题。

验证码本身也要认真设计。用密码学随机源生成，存哈希，几分钟内过期，只允许成功使用一次，并限制每个验证码和每个会话的尝试次数。不要暴露号码是否存在。先建账号记录再发短信，避免重试造出一个永远完不成的账号。

量流程，不要只量发送

返回 message ID 不等于验证码送达，验证码送达也不等于登录完成。用您能控制的事件搭漏斗：提交、回执、输入验证码、成功。再和服务商的视角对一遍。您的送达率和服务商的对不上，可能是回执没到您的处理程序，而不是短信没到手机。

指标一动，就回看流程。送达率稳定、完成率下降，问题在表单、验证码有效期或发送方。提交量稳定、送达率下降，问题在路由、号码或内容过滤。重发率上升，问题在送达时长。修数据指到的那一步，不要修最容易改的那一步。

给整条流程定一个复核日期。号码会换手，路由会变，模板会过时。上线时好用的流程，半年后可能悄无声息地失效，代码没变，服务商也没变。