抗钓鱼认证：真正让它具备抗钓鱼能力的是什么？
抗钓鱼认证经常被描述为“强 MFA”，但真正重要的区别并不只是使用了多少个认证因素。关键问题是：攻击者能否诱骗用户批准一次认证，然后把这次批准拿到其他地方继续使用。
现代钓鱼攻击往往是实时进行的。伪造网站可以把凭据中继到真实服务，截获一次性验证码，并立即转发批准请求。当认证证明通过密码学方式绑定到合法服务或来源，而不是一个可以被复制或中继的可重用秘密时，这种认证才真正具备抗钓鱼能力。
本指南介绍形成这种能力的主要设计属性，并说明 ZTXBAS 如何应用这些属性。
1. 为什么密码和一次性验证码容易被中继
密码、SMS 验证码和 TOTP 值都属于用户可能输入到错误位置的信息。
钓鱼代理可以：
- 展示一个与真实登录页面非常相似的页面
- 收集用户名和密码
- 将它们转发到合法服务
- 要求用户输入由真实服务生成的 SMS 或 TOTP 验证码
- 在验证码过期前立即中继
即使用户是在错误的网站上输入验证码，验证码仍可能有效，因为验证码本身并没有绑定到请求它的网站。
Push 批准改善了使用体验，但如果用户看到的只是“是否批准登录？”之类的通用提示，也可能存在类似问题。如果批准没有绑定到预期服务，用户可能会批准由钓鱼会话触发的请求。
2. 生物识别本身并不会自动带来抗钓鱼能力
指纹或人脸识别可以证明本地用户已经在某台设备上通过了生物识别验证。但仅凭这一点，并不能证明用户想要认证什么。
真正重要的问题发生在生物识别验证之后：
- 这次批准是针对哪个应用或来源？
- 用户能否看到这个目标？
- 最终生成的证明是否绑定到该目标？
- 该证明能否在其他应用上重放？
- 私钥是否会离开设备？
抗钓鱼能力来自围绕生物识别验证建立的协议，而不是来自生物识别传感器本身。
3. 来源绑定把批准与目标应用关联起来
来源绑定是 ZTXBAS 的核心控制机制。
当应用创建认证挑战时，会提交预期来源。只有该来源已经为此应用注册，ZTXBAS 才会接受请求。规范化后的来源会贯穿整个挑战流程，并在用户批准前显示在移动设备上。
例如，为以下来源创建的批准：
https://app.example.com
不能简单地改用于：
https://phishing.example.com
钓鱼来源没有为合法应用注册，而认证断言中会包含它真正签发时所绑定的来源。
这样，双方都有明确的内容可以验证：
- 用户能够看到自己正在批准的目标
- 依赖方应用收到的断言中包含同一个来源
后端在验证签名之后，仍然应该检查来源 claim 是否与预期值一致。抗钓鱼能力依赖于真正执行这种绑定，而不仅仅是在断言中携带一个字段。
4. 设备绑定密钥让私有凭据留在设备上
ZTXBAS 使用设备绑定的密码学密钥。私钥在可用时保存在设备的 Secure Enclave 或可信执行环境中，生物识别模板不会离开设备。
这改变了攻击者真正可以窃取的目标。
不存在一个可以由钓鱼网站收集并重复使用的共享“生物识别秘密”。服务器接收的是由已注册设备生成的密码学证明，而不是一个类似密码、可以重复使用的生物识别派生值。
换句话说，生物识别用于授权设备使用其本地私钥；生物识别数据本身不会发送给依赖方应用。
5. 短期签名断言降低被截获证明的价值
挑战成功后，ZTXBAS 会签发一个短期 ES256 JWT 身份断言。
断言中包括：
- 已认证用户
- 签发者
- audience 与来源
- 签发时间和过期时间
- 挑战标识符
依赖方应用使用 ZTXBAS 服务器发布的公共 JWKS 验证 JWT。在创建自己的应用会话之前，应验证签名、预期算法、过期时间、配置后的签发者以及预期来源。
由于断言已经签名并且生命周期很短，它并不等同于一个长期有效的 bearer 凭据。对重放有更高要求的应用还可以记录近期使用过的 challenge ID，并拒绝重复使用。
6. 依赖方应用本身也必须向认证服务证明身份
抗钓鱼并不只是用户侧的问题。
在 ZTXBAS 中，应用使用 HMAC-SHA256 对 API 请求签名。在创建挑战之前，服务器会验证请求是否来自已注册应用、请求的来源是否属于该应用，以及用户是否存在。
这样，任意钓鱼网站就不能简单地要求合法 ZTXBAS 服务器以另一个应用的身份，为自己创建有效挑战。
因此，应用密钥必须保留为服务器端凭据，绝不能暴露在浏览器代码或移动客户端中。
7. 用户仍然需要有用的上下文
密码学可以把请求绑定到某个来源，但用户体验仍然很重要。
一个可靠的批准流程应该显示足够的上下文，让用户知道自己正在批准什么。ZTXBAS 会在用户批准之前，在移动设备上显示已注册来源。
这有助于用户区分真实请求和意外请求，也避免只依赖没有目标信息的模糊批准提示。
组织仍应教育用户拒绝意外的认证请求。抗钓鱼能力降低了攻击者重用批准的能力，但并不意味着可疑提示可以被忽略。
8. 抗钓鱼认证不能替代其他访问控制
一次抗钓鱼认证事件提供的是一个明确的身份断言，但它不会回答所有授权问题。
应用仍可能需要判断：
- 用户是否应该拥有账号
- 用户属于什么角色
- 用户可以访问哪些资源
- 设备是否可信
- 是否需要额外批准
- 最终会话应持续多久
独立 ZTXBAS 向应用提供认证断言，而应用仍负责自己的会话和授权模型。
当 ZTXBAS 与 ZTXGate 一起授权时，生物识别能力会集成到 ZTXGate 中，可作为更广泛访问策略的一部分使用，而无需部署单独的 ZTXBAS 服务器。
9. 与 Passkey 和 WebAuthn 的关系
Passkey 和 WebAuthn 同样以抗钓鱼为设计目标，因为它们的密码学凭据绑定到合法 relying party，而不是由用户输入到任意网站中。
ZTXBAS 使用不同的交互模型：由服务器协调的生物识别 Push 流程生成一个签名 JWT，再由依赖方应用在服务器端验证。
这些方式可以互补，而不一定互相替代。浏览器应用可以使用 passkey 进行主要登录，同时使用 ZTXBAS 执行增强认证、移动流程或其他适合使用签名断言模型的非浏览器交互。
ZTXBAS 未获得 FIDO 认证。
10. 部署模式同样重要
当受保护系统必须在没有公共云依赖的情况下继续工作时，认证可用性本身就会成为安全架构的一部分。
独立 ZTXBAS 采用自托管方式运行，不需要 CoreZT 账号、遥测服务或许可证服务器。如果注册邮件所需的内部 SMTP Relay 等支持服务可以在本地提供，它也可以运行在隔离网络中。
集成到 ZTXGate 中的 ZTXBAS 功能同样可以在完全隔离的 ZTXGate 部署中运行，并且不需要单独的 ZTXBAS 服务器。
这并不意味着某一种部署模式在所有场景中都更好，但它提出了一个重要的架构问题：认证要持续工作，哪些外部服务必须保持可达？
11. 实用评估清单
评估任何被描述为“抗钓鱼”的认证系统时，可以询问：
- 认证证明是否通过密码学方式绑定到预期 relying party 或来源？
- 用户能否把主要认证证明输入或复制到攻击者控制的页面？
- 用户在批准之前能否看到目标？
- 私钥是否绑定到设备，并在可用时受到平台硬件保护？
- 服务器接收的是生物识别数据，还是仅接收本地生物识别验证已经成功的证明？
- 断言是否经过签名并且生命周期较短？
- 依赖方应用是否验证签发者、过期时间、audience/来源和算法，而不是只验证签名？
- 攻击者在没有应用服务器端凭据的情况下，能否创建有效挑战？
- 丢失设备如何撤销并重新注册？
- 认证过程中哪些网络或云依赖必须保持可用？
一个产品应该能够从协议和运行层面回答这些问题，而不只是给自己贴上“MFA”标签。
ZTXBAS 如何应用这些属性
ZTXBAS 将以下机制结合在一起：
- 已注册来源验证
- 批准前显示来源
- 由移动平台保护的设备绑定密钥
- 设备上的生物识别用户验证
- 通过 HMAC 认证的应用请求
- 短期 ES256 身份断言
- 基于 JWKS 的服务器端验证
最终，依赖方应用不仅可以验证是谁批准了挑战，还可以验证这次批准是为哪个来源签发的。
如需了解实施细节，可继续阅读技术文档，或直接评估独立 ZTXBAS 服务器。