SRP 不在协议中发送密码；这不等于取消密码、免疫钓鱼，也不意味着 verifier 无害。
通行密钥和 SRP 是两种不同的身份验证方式。通行密钥使用密钥对，可以消除对密码的需求。SRP 仍然基于密码，但在协议得到正确实现的情况下，不会把密码本身发送给服务器来证明自己知道它。
因此，“登录时不发送密码”与“无需拥有密码即可登录”并不相同。选择这些方式时，应依据钓鱼风险、凭据管理、恢复机制和实现质量，而不是笼统的“零知识”标签。
通行密钥改变了什么？
在基于通行密钥的身份验证中，服务保存公钥，用户通过控制私钥来确认登录。将凭据绑定到相应服务和源，是这种方式抵抗钓鱼的重要组成部分。FIDO 对通行密钥的说明。
并非所有通行密钥都必须在云端同步。有些绑定到一台设备或安全密钥；有些通过凭据提供商在设备之间转移。需要针对具体提供商检查恢复模型和同步保护。不能仅凭“云同步”就断定公司以可读取的形式保存密钥。
登录后的会话安全也是另一个问题。通行密钥不会自动消除设备上的恶意软件，也不会自动化解有效会话被盗的风险。
SRP 向服务器提供什么？
SRP 属于密码认证密钥交换协议家族。服务器不保存密码本身，而是保存盐值和验证值（verifier）等数据。双方通过交换协议消息，验证对秘密和共享密钥的知晓情况。
但是，verifier 并不是无害数据。RFC 5054 第 3.3 节明确指出，获得验证值的攻击者可以进行字典攻击来猜测密码。因此，“数据库被盗也完全无法进行离线猜测”的说法是错误的。
强密码、服务器保护、合适的参数、输入验证和登录尝试控制仍然必不可少。SRP 也不保证你输入密码的页面是安全的；恶意代码可以在协议运行之前截获密码。
公平比较
| 问题 | 通行密钥 | SRP |
|---|---|---|
| 用户是否需要记住服务密码？ | 通常不需要；但需要控制凭据 | 是，这种方式依赖于知道密码 |
| 服务为登录保存什么？ | 公钥及相关信息 | 验证值及相关参数 |
| 如何实现抗钓鱼能力？ | FIDO 设计将凭据绑定到服务/源 | 在协议中不发送密码，不足以使虚假的输入界面安全 |
| 云是否必不可少？ | 不是；也有设备绑定选项 | 协议本身不依赖第三方身份提供商，但需要身份验证服务 |
| 如何恢复？ | 取决于凭据类型和提供商 | 由账户和产品政策决定，而非由 SRP 这个名称决定 |
不能据此表对所有实现做出绝对排名。薄弱的恢复流程可能削弱强登录方式的优势。
账户登录与聊天密钥有什么关系？
身份验证告诉服务谁获准进行操作。消息加密密钥决定谁能打开内容。产品可能将两者关联起来，但这种关系必须有文档说明。
Livara 安全文档描述了用于登录的 SRP，并单独介绍了用于加密身份的 v7 恢复包。该包恢复的是身份，而不是聊天历史。因此，“登录密码正确”并不意味着“所有密钥和旧消息都已恢复”。
本文是概念性比较，不是对 Livara 所有登录方式的实际测试，也不是对产品精确实现某项 RFC 的认证。
选择时应提出哪些问题？
- 如果设备丢失，备用登录方式是什么，由谁控制？
- 恢复方式是否比主要登录方式更弱？
- 如何查看和撤销未知会话？
- 更改登录方式是否会改变消息密钥或关联设备？
- 同步凭据需要什么账户和哪些独立保护？
总结： 不要把通行密钥说成天生“因为使用云所以不安全”，也不要把 SRP 说成“因为零知识所以不怕泄露”。每种方式的边界以及产品的恢复政策，才是可靠比较的基础。
