短信验证的工作原理 — 技术解析
步骤 1：OTP 生成
当平台需要验证您的电话号码时，它会生成一个一次性密码（OTP）。以下是服务器端发生的情况：
- 用户提交电话号码 — 平台后端接收号码并验证其格式（国家代码、位数、有效前缀）。
- 生成 OTP — 创建一个加密随机代码，通常为 4-6 位数字。大多数实现使用
HMAC-SHA1或HMAC-SHA256，并使用基于时间的或基于计数器的种子（RFC 6238/RFC 4226 中的 TOTP/HOTP 标准）。 - 存储 OTP — 代码保存在服务器端，并带有过期时间戳（通常为 60-300 秒），并与电话号码关联。
- 应用速率限制 — 平台会检查最近为该号码请求了多少 OTP。大多数服务每小时允许每个号码尝试 3-5 次。
- 触发短信 API 调用 — 平台向其短信提供商发送请求，包含电话号码和消息内容。
OTP 本身通常只是一个随机数。平台不会以哈希形式将 OTP 嵌入消息中 — 它以明文形式发送在短信正文中。这是短信验证的一个基本安全弱点。
步骤 2：A2P 短信生态系统
A2P 代表应用程序到个人 — 从软件应用程序发送到人类手机的消息。这与 P2P（个人到个人）消息传递不同。A2P 生态系统拥有自己的基础设施：
短信聚合商
大多数平台不直接通过运营商发送短信。相反，它们使用短信聚合商 — 与全球数百家运营商保持连接的公司。主要聚合商包括：
- Twilio — 最大的短信 API 提供商。被 Uber、Airbnb、Stripe 和数千家其他公司使用。
- Vonage (Nexmo) — 国际短信路由的流行选择。
- Sinch — 在企业 OTP 交付方面表现强劲。
- MessageBird — 专注于欧洲的聚合商。
- Infobip — 新兴市场的主要参与者。
当 Instagram 向您发送 OTP 时，该消息很可能通过 Twilio 或类似的聚合商传输，然后再到达您的运营商。聚合商负责路由、运营商协商和交付确认。
短信路由
聚合商确定发送短信的最佳路线。对于美国号码，这可能意味着：
- 平台 API 调用 → 聚合商（例如 Twilio）
- 聚合商 → 运营商网关（例如 AT&T、T-Mobile）
- 运营商网关 → 短信中心 (SMSC)
- 短信中心 → 移动交换中心 (MSC)
- 移动交换中心 → 基站 → 用户手机
国际消息会增加复杂性。来自美国平台的 OTP 发送到印度号码，在到达目的地之前可能需要经过 2-3 个中间运营商。每一次跳转都会增加延迟和很小的失败几率。
步骤 3：SS7 和信令层
SS7（信令系统 7）是控制电话网络如何通信的协议套件。它开发于 20 世纪 70 年代，至今仍是全球电话通信的骨干。发送短信时，SS7 会处理：
- 号码查找（HLR 查询） — 发送运营商查询归属位置寄存器 (HLR)，以确定目标号码属于哪个运营商和网络。
- 消息路由 — SS7 信令决定消息在网络中的传输路径。
- 交付确认 — 接收方短信中心通过 SS7 信令发送交付回执。
SS7 安全问题
SS7 是在一个只有受信任的电信运营商才能访问网络的时代设计的。如今，数千个实体可以访问 SS7，这造成了安全漏洞：
- 短信拦截 — 拥有 SS7 访问权限的攻击者可以将短信重定向到自己的设备。这已在针对银行 2FA 的真实攻击中得到证实。
- 位置跟踪 — SS7 查询可以暴露手机的物理位置。
- 号码欺骗 — SS7 允许发送看起来来自不同号码的消息。
这些漏洞是为什么安全专家建议从基于短信的 2FA 转向基于应用程序的身份验证器（TOTP）或硬件密钥（FIDO2）的原因。然而，对于初始账户验证（证明您拥有一个号码的访问权限），短信仍然是行业标准，因为它覆盖范围最广。
步骤 4：虚拟号码如何接收短信
虚拟电话号码通过软件取代物理 SIM 卡和无线电组件来工作。以下是虚拟号码如何接收 OTP：
- 号码分配 — 虚拟号码提供商从运营商那里租赁号码块。这些是具有有效运营商注册的真实电话号码。
- SIM 卡库或软 SIM 卡 — 提供商在硬件中运行物理 SIM 卡（包含数百或数千张 SIM 卡的 SIM 卡库），或使用运营商级别的软件集成来接收消息。
- 短信到达运营商 — OTP 消息像任何其他短信一样被发送到与虚拟号码关联的运营商。
- 消息转发 — SIM 卡库或运营商集成捕获传入的短信，并通过 API 将其转发到提供商的后端。
- 用户看到代码 — 提供商的仪表板或 API 向用户显示收到的短信。
关键见解：从发送平台的角度来看，虚拟号码与物理电话完全相同。短信遵循相同的路由路径。区别在于最后一公里 — 消息不是显示在手机屏幕上，而是被软件捕获。
步骤 5：平台端验证
用户在平台上输入 OTP 后，服务器端验证会发生：
- 代码比较 — 平台将提交的代码与存储的 OTP 进行比较。
- 过期检查 — 如果 OTP 已过期（通常为 60-300 秒），则验证失败。
- 尝试计数 — 大多数平台允许 3-5 次不正确的尝试后锁定验证。
- 号码分类 — 一些平台会检查号码是否为 VoIP/虚拟号码数据库，以标记潜在的滥用。
- 成功或失败 — 如果代码匹配且未过期，则电话号码将被标记为已验证。
平台如何检测虚拟号码
一些平台会尝试阻止虚拟号码。他们使用的方法：
| 检测方法 | 工作原理 | 有效性 |
|---|---|---|
| 号码类型查找 | 查询运营商数据库以检查号码是移动、固定电话还是 VoIP | 中等 — 许多虚拟号码被注册为移动号码 |
| 运营商数据库检查 | 将号码与已知的 VoIP 提供商范围进行比较 | 中等 — 对大型提供商有效，但会遗漏小型提供商 |
| HLR 查询 | 查询归属位置寄存器以获取 SIM 卡详细信息 | 对于检测纯软件号码有效，对于 SIM 卡库号码效果较低 |
| 行为分析 | 跟踪同一号码段创建了多少账户 | 长期有效，但需要数据积累 |
虚拟号码提供商通过使用注册为移动线路的运营商级号码、维护多样化的号码池以及频繁轮换号码来应对这些检测。检测规避周期正在进行中。
为什么尽管存在缺陷，短信验证仍然存在
短信验证存在众所周知的安全漏洞，但它仍然是主流方法。原因在于其实用性：
- 普遍覆盖 — 每部手机都可以接收短信。无需安装应用程序。这覆盖了功能手机和旧设备上的数十亿用户。
- 用户熟悉 — 每个人都明白“输入我们发送的代码”。无需解释。
- 实施成本低 — 短信 API 很便宜。Twilio 在美国每条短信收费约 0.0075 美元。大规模使用时，每次验证只需几美分。
- 可接受的安全权衡 — 对于大多数用例（社交媒体注册、外卖账户），短信提供了足够的摩擦来阻止自动滥用，而无需硬件安全密钥。
行业正缓慢转向替代方案。密码钥匙（FIDO2）、基于应用程序的 TOTP 和推送通知正在获得普及。但对于初始电话验证 — 证明用户控制着一个电话号码 — 短信仍然是标准。
虚拟号码在此生态系统中的作用
虚拟号码占据了一个特定的细分市场：它们提供电话号码级别的访问权限，而无需物理设备。这对于合法的场景很有用，包括：
- 隐私保护 — 不将您的真实号码泄露给可能出售您数据的平台。请参阅我们关于 VerifySMS 与免费短信网站 (receive-smss.com) — 为什么付费更好，了解隐私在此处的重要性。
- 多账户管理 — 在同一平台上运营多个账户的企业需要为每个账户使用唯一的号码。
- 国际访问 — 在 美国虚拟电话号码 — 非VoIP号码 的平台上验证账户，而无需拥有本地 SIM 卡。
- 开发和测试 — QA 团队需要大量号码来测试 OTP 流程，而无需管理物理设备。
从技术角度来看，虚拟号码之所以有效，是因为它们利用了短信验证仅证明对号码的控制权 — 而不是号码在某人手中的物理手机上 — 这一事实。只要号码有效且可以接收 A2P 消息，验证就会成功。
高级：OTP 交付优化
如果您是实施短信验证的开发人员，以下是可靠交付的技术注意事项：
- 明智地使用发件人 ID — 在支持字母数字发件人 ID 的国家/地区，请使用您的品牌名称。在美国，请使用专用短代码或 10DLC（10 位长代码）以获得最佳交付率。
- 实施备用路由 — 使用多个短信聚合商，这样如果一个路由失败，消息将通过另一个路由重试。
- 保持消息简短 — OTP 消息应少于 160 个字符（一个短信段）。多段消息的失败率更高。
- 设置适当的超时 — 120 秒是最佳选择。太短会导致误报失败；太长则允许拦截的代码被使用。
- 记录交付回执 — 跟踪消息是已交付、待处理还是失败。这些数据有助于识别特定运营商的问题。