短信验证码、邮箱验证码和身份验证器，SaaS 登录安全应该怎么选择

SaaS 登录系统经常面对一个看似简单、实际上很难回答的问题：到底应该让用户收短信验证码、收邮箱验证码，还是打开身份验证器输入 TOTP？

三种方式都能完成身份验证，但它们承担的安全能力并不相同。短信和邮箱验证码主要依赖用户已经控制的通信账户，TOTP 则依赖预先建立的共享密钥并在用户设备本地生成一次性密码。对于企业 SaaS 来说，更现代的设计还应该把 Passkey 和 WebAuthn 纳入选择范围。

因此，登录安全不能简单理解成“哪一种验证码最安全”。更合理的思路是根据账户风险、用户群体、设备环境、恢复流程以及业务操作的敏感程度，建立分层认证体系。

短信验证码是最容易被用户理解的一种方案。用户输入手机号后，服务端生成一次性验证码，通过 SMS 通道发送到用户设备，用户再把验证码输入登录页面。

它最大的优势是普及率高。用户通常不需要提前安装验证器，也不需要记住额外密码。对于面向大量普通消费者的 SaaS 产品，短信仍然是一种非常方便的身份验证手段。

但短信并不属于高强度认证方式。手机号本身并不是一个强密码，SMS 通道也不是专门为身份认证设计的安全信道。攻击者可能通过 SIM swap，也就是通过运营商渠道把号码转移到另一张 SIM 卡，进而接收短信验证码。用户还可能遭遇钓鱼网站、社交工程或者恶意软件攻击。

因此，短信验证码最适合被看作一种方便的验证因素，而不是高风险账户唯一的安全边界。

短信还有另外一个现实问题，就是成本和供应链。SaaS 平台需要依赖 SMS Provider 发送大量消息，跨国业务还会受到国家、地区、运营商、Sender ID、漫游以及短信投递质量等因素影响。短信并不是免费的基础设施，大规模使用时，认证成本本身也会成为 SaaS 运营成本的一部分。

邮箱验证码与短信验证码的逻辑类似。系统生成一次性验证码，通过用户已经绑定的邮箱发送，用户从邮件中取得验证码并完成验证。

它的优势在于成本通常低于短信，而且对于企业 SaaS 用户来说，邮箱往往本来就是账号体系的重要组成部分。企业员工通常已经拥有公司邮箱，因此邮箱验证可以自然地融入邀请注册、账号激活、密码重置和登录流程。

但邮箱验证的安全强度取决于邮箱账户本身。如果攻击者已经控制了用户邮箱，那么邮箱验证码也就失去了独立的安全价值。钓鱼攻击同样可以诱导用户把邮件验证码输入攻击者控制的网站。

邮件还有一个明显的体验问题。邮件投递并不是实时通信机制，用户可能需要等待几十秒甚至更长时间才能收到验证码。邮件被垃圾邮件过滤、企业网关延迟或者邮件服务异常，也可能导致用户认为 SaaS 登录系统发生故障。

因此，邮箱验证码对于低风险登录、账号验证和账户恢复非常实用，但不应该被包装成一种高强度认证方案。

TOTP 的工作方式与短信和邮箱完全不同。

TOTP，也就是 Time-based One-Time Password，是基于时间的一次性密码。用户在启用身份验证器时，服务端与身份验证器应用建立一个共享密钥。之后，验证器根据共享密钥和当前时间计算一次性密码，服务端使用相同的秘密和时间窗口验证用户输入的代码。

这里需要纠正一个非常常见的错误：TOTP 不是服务器向手机“推送”验证码。Google Authenticator 等传统身份验证器通常不需要网络连接来生成 TOTP。密码是在设备本地根据共享密钥和时间计算出来的。

这意味着攻击者不能像拦截普通短信那样，通过控制 SMS 通道直接获得 TOTP。即使手机暂时没有网络，身份验证器通常仍然能够生成代码。

但 TOTP 也不是不可攻破的。如果用户被钓鱼网站诱导，把刚刚生成的 TOTP 输入攻击者控制的页面，攻击者仍然可以在短时间内利用这个验证码完成登录。这类攻击属于实时钓鱼或中间人式认证代理攻击，也是为什么现代高安全场景越来越重视 Passkey 和 WebAuthn。

TOTP 的另一个问题是账户恢复。

用户换手机、丢手机、删除身份验证器、重置设备或者没有保存恢复代码时，如果 SaaS 平台没有设计可靠的恢复流程，用户可能直接失去账户访问权限。

因此，一个成熟的 TOTP 系统不能只设计“输入六位数字”这一页。启用 MFA 时应该提供安全的恢复代码，并设计账户恢复、设备变更和高风险恢复操作的验证流程。恢复流程本身就是认证系统的一部分，甚至可能成为攻击者绕过 MFA 的目标。

如果从安全强度来看，Passkey/WebAuthn 已经成为非常值得企业 SaaS 考虑的方案。

Passkey 通常基于公钥密码学。用户设备保存私钥，服务端保存对应的公钥。登录时，设备通过生物识别、设备 PIN 或其他本地解锁方式授权使用私钥完成认证。

这种模式与密码和一次性验证码存在根本区别。服务端不需要保存用户的密码，也不需要保存能够直接登录的 TOTP 秘密。对于支持现代浏览器和设备的 SaaS 产品，Passkey 可以显著减少传统密码和 OTP 被钓鱼的问题。

这也是为什么不能把 SaaS 认证设计简单归纳成“短信、邮箱、TOTP 三选一”。如果产品面对企业客户或者保存敏感数据，应该考虑 Passkey/WebAuthn 作为高安全认证方式，同时保留适当的兼容方案。

另外，登录安全不能只看第二因素。

例如一个 SaaS 平台即使使用 TOTP，如果允许攻击者无限尝试验证码，那么六位数字的有限搜索空间仍然可能成为攻击目标。因此服务端必须实施登录限速和验证码尝试次数控制。

限速也不能只按照 IP 地址执行。大量用户可能共享同一个 NAT 出口，而攻击者又可以使用大量代理 IP。比较合理的策略通常会综合账号、IP、设备信号、请求频率和失败次数等因素进行风险控制，同时避免因为过度限制导致正常用户无法登录。

验证码本身也应该具备短生命周期、单次使用和服务端验证等属性。验证码不能在成功使用后继续有效，也不能因为重复提交而被无限尝试。

对于短信和邮箱验证码，还应该设置发送频率限制。否则攻击者可以利用“发送验证码”功能对某个电话号码或邮箱地址进行短信轰炸、邮件轰炸，甚至利用 SaaS 的短信供应商制造成本。

因此，“验证码防暴力破解”与“验证码防滥用”是两个不同的问题。前者保护验证过程，后者保护发送接口和整个认证服务。

设备指纹也经常被加入 SaaS 登录系统，但它不应该被理解成一个永久、可靠的用户身份。

浏览器版本、操作系统、IP 地址、时区、Cookie、设备特征等信息可以作为风险信号。例如一个账户一直在加拿大登录，突然从完全不同的环境发起大量登录尝试，系统可以要求额外认证。

但 IP 会变化，用户可能使用 VPN、企业代理、移动网络或者共享网络，浏览器指纹也可能因为浏览器升级、隐私保护机制或者设备变化而改变。因此设备信号更适合作为风险评分因素，而不是直接作为“这个设备就是本人”的证明。

真正成熟的 SaaS 登录系统通常采用风险分层。

普通登录可以采用密码加 TOTP、Passkey 或其他适当认证方式。对于低风险场景，可以允许用户使用邮箱等更方便的方式完成登录。对于异常环境、高风险账户或者敏感操作，则提高认证要求。

例如，一个普通员工登录项目管理系统和一个管理员准备修改组织安全策略，并不应该拥有完全相同的认证要求。

对于管理员、财务人员、拥有生产环境权限的工程师以及可以访问敏感客户数据的账户，应该优先考虑抗钓鱼能力更强的认证方式。Passkey/WebAuthn 是一个重要选择，TOTP 可以作为兼容和备用方案，而短信更适合承担恢复或兼容场景中的辅助角色。

对于资金转账、修改银行账户、修改组织管理员、删除整个租户、生成高权限 API Key 等敏感操作，也不应该仅仅依赖用户已经登录这一事实。

这类操作可以要求重新认证，也可以根据风险要求使用更强的认证因素。登录成功之后的会话并不意味着用户在未来数小时内执行任何敏感操作都无需再次证明身份。

会话管理同样是 SaaS 登录安全的核心。

用户完成认证以后，服务端通常会建立 Session。Session ID 应该具有足够的随机性，并通过安全 Cookie 属性进行保护，例如 Secure、HttpOnly 和适当的 SameSite 配置。

登录成功以后还需要防止 Session Fixation。用户从未认证状态进入认证状态时，应该切换到新的 Session ID，而不能继续使用攻击者可能提前设置的旧会话标识。

退出登录、修改密码、修改 MFA 配置等敏感操作，也应该考虑撤销相关会话和刷新令牌。否则用户虽然已经改变了账户安全设置，攻击者之前获得的长期会话仍然可能继续有效。

如果使用 JWT，也不要把 JWT 与“更安全的登录系统”直接画等号。JWT 是一种令牌格式，并不是完整的认证架构。Token 生命周期、存储位置、刷新机制、撤销策略以及权限检查才决定实际安全性。

OAuth 2.0 也需要正确理解。OAuth 2.0 主要解决授权问题，而 OpenID Connect 在 OAuth 2.0 之上提供身份认证能力。企业 SaaS 如果需要接入 Google、Microsoft 或企业身份提供商，通常需要从 OAuth/OIDC 的实际角色出发设计，而不是简单地把 OAuth 当作一种验证码技术。

账户恢复则是经常被忽略的薄弱环节。

一个 SaaS 平台可能拥有非常强的 Passkey 和 MFA，但如果用户点击“我无法访问账户”，然后只需要输入一个容易猜测的信息就可以关闭 MFA，那么攻击者仍然可以通过恢复流程绕过整个认证体系。

所以账户恢复的安全级别不能明显低于正常登录。尤其是企业管理员、财务账户和拥有大量客户数据访问权限的账户，恢复操作可能需要额外验证、人工审核或者企业身份提供商介入。

从工程实现来看，短信、邮箱、TOTP、Passkey 并不是互相完全替代的关系。

短信的优势是覆盖面和便利性，缺点是抗钓鱼能力有限，并依赖通信供应链。邮箱验证码成本较低，适合账号验证和部分低风险流程，但安全性受邮箱账户保护水平影响。TOTP 不依赖短信网络，安全性通常优于 SMS，但仍然可能受到实时钓鱼影响，而且存在设备迁移和恢复问题。Passkey 则采用公钥密码学，对传统密码和 OTP 钓鱼具有更强的抵抗能力，但需要考虑设备、浏览器和用户教育等兼容因素。

对于一个面向普通消费者的 SaaS 产品，可以根据业务风险采用密码加第二因素、邮箱登录或者 Passkey，并将 SMS 作为兼容手段之一。对于企业 SaaS，尤其是涉及客户数据、生产系统和管理员权限的产品，则应该逐步把 Passkey/WebAuthn、TOTP、企业 SSO 和风险控制结合起来。

最终，SaaS 登录安全不是选择一个“最安全的验证码”就结束了。认证只是整个安全边界的一部分，后面还包括 Session 管理、授权检查、租户隔离、密码重置、账户恢复、登录限速、审计日志以及高风险操作的重新认证。

如果把整个认证体系拆开来看，短信和邮箱解决的是通信渠道验证，TOTP解决的是基于共享密钥的一次性认证，Passkey解决的是基于公钥密码学的现代认证，Session 管理负责维持认证状态，Authorization 决定用户登录以后能够做什么，而 Tenant Isolation 则决定一个 SaaS 用户是否能够越权看到另一个客户的数据。

企业真正需要设计的不是一个验证码页面，而是一条完整的认证与授权链路。对于低风险用户，系统应该足够方便；对于管理员和敏感业务，系统应该提高认证强度；对于异常行为，系统应该动态增加验证；对于账户恢复，系统不能留下比正常登录更容易绕过的后门。

这才是现代 SaaS 登录安全真正需要解决的问题。