聊天服务的服务器被入侵，并不一定意味着所有消息都会被读取。后果取决于存储了哪些数据、密钥位于何处以及攻击者的访问权限。即使聊天正文正确采用了端到端加密，账户信息、时间、群组成员关系和投递路径仍可能是敏感信息。
评估事件时，首先要问攻击者拿到了什么：数据库副本、基础设施密钥、运行中的服务器，还是软件发布系统？这些情形的后果并不相同。
数据库被盗与服务器受控并不相同
只持有旧数据库副本的攻击者，能接触的仅限于当时记录的数据。控制运行中的服务则可能使其记录新数据、窃取会话、更改响应，或尝试替换联系人的密钥。软件发布链被入侵又是另一种风险：端点上的恶意代码可能在加密之前或解密之后看到明文。
因此，“数据库不包含消息正文的密钥”是一项重要说明，但不能完整回答所有类型的入侵风险。
比较五种架构模式
这些是教学用的模式，而不是对五款产品的排名。同一项服务的不同功能可能采用多种模式。
| 模式 | 从数据库可获取的数据 | 重要边界 |
|---|---|---|
| 明文消息和密码 | 内容与凭据可以直接读取 | 两类数据都缺乏适当保护 |
| 哈希密码、明文消息 | 内容可读；可能可以测试密码猜测 | 密码存储方法的质量并不保护聊天正文 |
| 使用服务器密钥加密内容 | 密文；能否读取取决于是否能访问密钥 | 密钥与数据真正分离很重要 |
| E2EE 聊天，但提供方可访问备份 | 实时聊天可能受保护，但历史副本有独立的泄露路径 | 必须检查备份策略和密钥 |
| E2EE 聊天，配合加密恢复和独立密钥 | 密文与运行数据；内容保护取决于设计和密钥保护 | 设备、恢复助记词和联系人身份认证仍然重要 |
服务器磁盘加密对于原始磁盘被盗的情况有帮助。如果攻击者还控制运行中的服务或解密密钥，就不能假设仍有相同的保护。E2EE 的目标是让中间服务不持有读取受保护内容所需的密钥。
元数据会显示什么？
元数据可能显示哪些账户彼此通信、何时活跃、属于哪些群组，以及传输了多少数据。这些信息不是消息正文，但对于了解关系网络或活动模式很有价值。
Livara 安全页面明确说明了运行数据的存储与处理，包括路由、成员关系、时间、密文大小和投递状态。不能把私人内容保密理解为完全匿名，或服务器上完全没有任何数据。
SRP 并不能让账户数据免受密码猜测风险
SRP 是一种无需直接发送密码本身、即可证明知道密码的方法。服务器仍保存验证数据，即 verifier。RFC 5054 的安全章节说明，验证值被盗可能使猜测密码的字典攻击成为可能。
因此，“密码不在网络上传输”与“不存在可被窃取的密码相关数据”并不是同一回事。独特且强健的密码、设备保护和适当的事件响应仍然必要。SRP 也不能代替内容加密或登录会话保护。
Livara 公布了哪些边界？
Livara 的安全文档为直接消息描述了 LVR1，为受保护群组描述了 LGS1。群组保护取决于其实际状态；不兼容的旧群组不应被标为 E2EE。公开频道不在这一保密边界之内。
同一文档将 v7 恢复描述为上传前就受到保护的加密身份包。这一流程恢复的是密码学身份，而不是聊天历史。恢复助记词泄露，或持有密钥的设备暴露，与仅数据库被盗是不同的情形。
这些是产品已发布的说明，不是本文独立审计的结论。仅仅提到 AES 或 ML-KEM，也不能证明密钥管理和应用实现正确。
事件通报时，应提出哪些问题？
- 涉及哪些时间段和系统？笼统地说“用户信息”并不够。
- 攻击者可接触的是明文、文件、密钥、验证值、登录会话，还是仅有密文？
- 攻击者是否能够更改服务或交付给用户的软件？
- 需要通过官方渠道采取哪些措施：退出会话、更改密码、更新，或检查联系人身份？
- 建议的恢复操作是否可能丢失本地历史？卸载应用之前，先阅读其限制。
不要使用陌生消息中的链接进行“紧急账户验证”。应独立打开官方地址查看通报。Livara 威胁模型有助于理解一般边界；真实事件的影响范围则必须依据该事件本身的证据确定。
