短信验证与认证器应用：哪个更安全？

两个因素，两种完全不同的威胁模型

当服务要求第二因素时，它要求你证明两件事：你知道密码，以及你拥有其他东西。这个"其他东西"是 SMS 和认证器应用的区别所在，这些差异只有在查看特定攻击场景时才重要。

短信要求服务的消息提供商向一个电话号码发送一次性代码。拥有权通过接收代码的设备（即控制 SIM 卡或虚拟号码路由的人——关键是，不一定是你）来确立。

认证器应用如 Google Authenticator、Authy、Aegis 或 2FAS，使用在注册时交换的共享密钥在设备本地生成代码。拥有权通过持有包含密钥的设备来确立。代码从不通过网络传输给你——它在你的口袋里计算。

这一单一差异——从网络到达代码与本地计算代码——是两种方法之间几乎所有安全差距的来源。它们防护的威胁、它们无法防护的威胁，以及恢复路径都源于此。

SMS 一次性代码如何被攻击

SMS 攻击面异常宽泛，因为短信在到达你之前接触多个系统。

SIM 卡互换是最受关注的攻击，在 2026 年仍然有效。攻击者通过社交工程说服运营商代表——或贿赂他们——将你的号码转接到他们控制的 SIM 卡。一旦 SIM 卡属于他们，所有本应发送给你的短信，包括密码重置代码，都会落入他们手中。关于高调 SIM 卡互换盗窃的报道并未减少；这种技术足够有利可图，半组织化的犯罪团伙一直在进行。

SS7 窃听利用自 1980 年代以来连接世界电话网络的运营商间信令协议的弱点。获得 SS7 网关的访问权——在灰色市场交易中悄悄出售——攻击者可以重定向 SMS 路由，无需接触你的 SIM 卡。这比 SIM 卡互换需要更多技术，在有针对性攻击之外较罕见，但已经对银行多次演示过。

运营商内部人员和支持人员的钓鱼是相关类别。运营商的客户支持工具对运营商来说只是普通 CRM 软件。有动机的攻击者若钓鱼获得支持代理的会话，可以发起转接、更改路由和读取 SMS 日志。

Smishing是最简单的攻击：攻击者向你发送看起来像合法验证请求的伪造短信，希望你将代码输入钓鱼页面。这是这里唯一认证器应用也不会遭受的攻击，因为如果用户被骗，认证器代码也可能被钓鱼。

共同点：短信依赖多个你无法控制的系统，其中任何一个被破坏都足以了。认证器代码仅依赖你物理持有的设备。

认证器应用的故障模式

认证器应用并非无懈可击。它们有自己的故障模式。

**钓鱼仍然有效。**精心制作的伪造登录页面可以实时要求你输入密码和 TOTP 代码，页面后的脚本在 30 秒窗口过期前同时向真实服务提交两者。这是 2026 年受认证器保护账户的主导攻击，以及 WebAuthn / Passkeys 逐渐取代 TOTP 的原因。

**没有备份的设备丢失是致命的。**如果你在单部手机上设置 Google Authenticator，丢失手机，且从未保存恢复代码，你会被锁定在每个账户之外。恢复权在每项服务的支持团队手中，通常需要数天且需要身份证明。

**云同步认证器引入新的攻击面。**Authy 在 2024 年曾发生数据泄露，泄露了与账户相关的电话号码。同步到 iCloud 或 Google Drive 的认证器应用将你的密钥暴露给能够破坏该账户的任何人。权衡是真实的：丢失设备或丢失云，选择哪个让你不太在意。

**设备上的恶意软件。**受感染的手机可以从屏幕截图或屏幕录制中读取 TOTP 代码。这是专门的攻击，对普通用户罕见，但对高价值目标有文件记录。

**OTP 重复和时间偏差。**如果设备时钟漂移，代码无法验证。如果同一密钥在两个设备上注册且其中一个被盗，两个都会生成有效代码，直到密钥被撤销。

并排比较

正确理解这个表：它不是"认证器赢了所有行"。SMS 在可访问性、账户恢复和零配置设置上赢了。对于随意论坛登录，SMS 没问题。对于你的银行、邮箱或加密交易所，重要的行是"抵抗 SIM 卡互换"，在那里 SMS 表现很差。

SMS 2FA 是正确选择的情况

有真实情况下 SMS 2FA 是更好的选择：

• **用户没有智能手机。**年长的亲戚、某些工作场所、任何使用功能手机的人。SMS 是他们唯一能使用的第二因素。
• **账户恢复占主导。**对于低价值账户，被锁定的成本（无法检索食谱网站登录）超过被攻击的成本（有人窃取你保存的食谱）。
• **威胁模型是机会性的，不是有针对性的。**随机攻击者不会 SIM 卡互换随机人员；他们瞄准高价值目标。如果你不是高价值目标，SMS 足以阻止机会性攻击。
• **你正在使用虚拟号码。**用于一个特定账户、从不与你真实身份绑定的虚拟电话号码，由于攻击者必须首先识别哪个提供商托管它，因此 SIM 卡互换的难度要大得多。这不会消除 SS7 风险，但在最常见的攻击上大幅提高了门槛。许多用户通过短信激活流程注册账户，正是为了验证线与他们的主号码脱钩。

"虚拟号码用于低风险账户"模式越来越常见：对每个账户使用 SMS 2FA 搭配一次性号码，为持有金钱或通信的账户保留 TOTP 或硬件密钥。

认证器应用是必要的情况

如果以下任何情况适用于你的账户，认证器应用（或更好的是硬件密钥）是正确的基线：

• 账户持有金钱——银行、经纪、加密交易所、支付处理商
• 账户持有长期通信——邮箱，特别是备份其他账户的邮箱
• 账户用于工作——企业 SSO、源代码控制、云基础设施
• 账户包含受管制数据——医疗、政府服务
• 账户泄露会个人暴露你——主社交媒体、约会应用，或任何与你真实身份绑定的东西

对于这些，SIM 卡互换风险压过一切。将认证器与 WebAuthn / 硬件密钥搭配使用，在支持的地方。对于加密交易所专门，计算方式不同：你通常需要两者，因为即使在设置 TOTP 后交易所也要求 SMS 作为备用。

真正有效的混合设置

对于大多数用户，最强的实际设置是分层的：

1. 通过备份的认证器进行 TOTP 作为主要第二因素。带加密本地备份的 Aegis、iCloud 备份的 2FAS，或如果你接受云信任模型的 Authy。
2. 打印在纸上的恢复代码存储离线。大多数服务在 TOTP 设置时给你 8 到 16 个代码。把它们当现金对待。
3. 账户上的虚拟 SMS 号码，与你的主号码隔离，仅用于需要它作为备用的服务。号码无需是你的"真实"号码——只需可达。对稳定性使用长期租赁号码或对经常登录的账户使用专用 DID。
4. 硬件密钥（YubiKey、Feitian）在顶端用于支持它的账户。以这里列出的任何其他东西无法做到的方式抵抗钓鱼。

这个设置每年成本大约二十美元（租赁号码加可选硬件密钥），保护你免受除完整设备破坏外的每个现实攻击。

如果你今天开始要迁移什么

如果你读到这里且你的账户都是 SMS 唯一的，按顺序做这些：

1. **邮箱首先。**它是其他一切的恢复账户。本周将其移至 TOTP。
2. **财务账户其次。**银行、经纪、支付处理商。某些银行仍然抵抗 TOTP——推动他们，或选择提供它的银行。
3. **任何与你真实身份绑定的东西。**主社交媒体、政府门户、医疗。
4. **长期价值账户。**云存储、代码库、任何你会因此失去工作的东西。
5. **其他一切。**SMS 对长尾很好。如果你有数百个账户，向它们投放虚拟号码比为每个注册 TOTP 更快。

所有这一切的要点不是 SMS 不安全而认证器应用安全。而是它们对不同威胁失败，正确选择取决于你在保护什么。关于基础 SS7 弱点的外部视角，SS7 攻击的维基百科总结是公平的起点。

选择与威胁匹配的第二因素。在重要的地方分层它们。如果你完全在使用 SMS，至少在不是你主号的号码上做——那一个改变以零持续成本关闭了最简单的攻击向量。