先说为什么：密码不加密会发生什么
想象一下，密码像你的家门钥匙。把钥匙随手放在桌上（明文保存），任何来访的人、清洁工、甚至窗外的窥探者都可能拿走。加密就是把钥匙放进一个带锁的保险箱，只有你知道开锁的方式。但保险箱本身也不能随便写下密码贴在上面，所以要把开锁方式变得难以被猜到或窃取。
用户视角：怎么做最实用（一步步）
下面给个清晰可执行的路线，按重要性排序，哪个容易做就先做哪个。
- 优先使用端到端加密的密码管理器：比特浏览器自带的密码管理器如果支持“主密码”或“零知识同步”（zero-knowledge E2EE），建议启用。第三方如1Password、Bitwarden（自托管）等也都是成熟选择。
- 设置强主密码/短语：主密码是解密你所有密码的秘密钥匙，建议用长短语（4-6个随机词）或10+字符复杂组合，别用浏览器账号密码做为主密码。
- 启用多因素认证（MFA）：对浏览器账号和同步服务启用2FA（基于TOTP或U2F/WebAuthn的硬件密钥），即使密码泄露也能挡住攻击。
- 开启硬件保护：在支持的设备上，让密钥存储在Secure Enclave/TPM或硬件安全模块（YubiKey等），增加物理防护。
- 对同步数据实现端到端加密：检查浏览器同步设置，确认“仅端到端加密”或“仅本地解密”选项已打开，避免把明文或可直接解密的密钥放到云端。
- 备份要加密：导出或备份密码库时，务必用强密码再次加密或把备份放在加密的存储器（如 VeraCrypt 容器、受保护的云存储）。
- 防止截屏/剪贴板泄露：复制密码后尽快清空剪贴板，避免在不可信设备上使用自动填充。
- 设备与浏览器要打补丁：很多泄露来自漏洞或恶意扩展，及时更新、只安装可信扩展并限制扩展权限。
开发者/浏览器实现侧：安全设计要点（讲清楚原理）
按费曼法，把每一层都讲清楚：怎么从“密码明文”变成“不可读的加密数据”，以及如何安全地恢复。
总体架构（通俗版）
保存流程可以拆成三步：派生密钥 → 用密钥加密密码项 → 安全存储/同步。取回时是逆序：下载加密数据 → 用派生密钥解密。关键在于派生密钥的安全性和密钥的存放方式。
关键技术选择（更具体）
- 密钥派生函数（KDF）：优先Argon2（抗GPU、抗内存攻击），次选PBKDF2（要提升迭代次数）。KDF需要随机salt并合理配置参数（内存、时间、并行度）。
- 对称加密算法：使用AEAD（Authenticated Encryption with Associated Data），如AES-256-GCM或ChaCha20-Poly1305，保证机密性和完整性。
- 每项使用独立随机IV/nonce和可选的每项salt：避免重复nonce引发的灾难性泄露。
- 密钥封装（Key wrapping）与密钥层级：不要直接用主密码加密全部条目，采用数据密钥（DEK）加密条目，再用主密钥（KEK）加密DEK，便于密钥轮换。
- 端到端加密（E2EE）同步：服务器只存加密文本与元数据（必要时），真正密钥只由客户端派生或保存在硬件模块中，服务器无解密能力。
- 零知识与审核：实现零知识协议并通过外部安全审计、公开算法参数。
内存与生命周期管理（容易被忽略）
解密时要注意：不要把明文密码写入长期日志，尽量在内存中使用受保护的缓冲区，使用完立即清零。移动端/桌面端可利用操作系统提供的受保护内存API。
具体的保存与读取流程示例（一步步，看起来像指南）
下面这个流程可以当作开发或高级用户实施参考：
- 用户输入主密码（或解锁硬件密钥）；
- 客户端生成随机salt（如果第一次），用KDF（Argon2）和salt派生KEK；
- 为每个密码条目生成随机DEK和随机nonce；用DEK + AEAD加密条目；
- 用KEK加密DEK（密钥封装），把封装后的DEK、加密条目、nonce与salt一起存储或同步；
- 恢复时，从服务器或本地读取封装数据，用KEK解封DEK，再用DEK解密条目。
| 存储项 | 内容/说明 |
| salt | KDF用的随机值（每用户或每库不同） |
| 封装的DEK | 用KEK加密后的数据密钥 |
| 加密条目 | AEAD加密后的用户名、密码、备注等 |
| nonce/IV | 每条目的随机值，避免重用 |
一些数值建议（实用、不要盲从）
- KDF：Argon2id，内存成本至少几百MiB（视设备能力），时间成本调整让每次派生需要几十到几百毫秒。
- AES：使用AES-256-GCM或ChaCha20-Poly1305，密钥长度256位。
- 随机数：使用操作系统安全随机源（如Linux的getrandom、Windows的CryptGenRandom或Cryptography API: Next Generation）。
常见误区与攻击面（知道敌人在干嘛）
- 误区：“云端同步就是不安全”——不完全对，关键看是否端到端加密；云同步本身提供可用性，不代表安全缺失。
- XSS/扩展攻击：浏览器扩展或恶意脚本可以窃取未受保护的表单内容或自动填充的数据，最坏会在页面上截取密码。
- 物理攻击：未锁屏的设备或被植入后门的设备会直接暴露密钥。
- 服务器侧泄露：如果服务器存储了可直接解密的数据或密钥，一旦被攻破，用户密码将直接泄露；零知识设计能缓解这一点。
用户的快速检查清单（方便记）
- 浏览器同步是否启用了端到端加密？
- 是否设置并记住了强主密码？（不是短密码）
- 是否启用了多因素认证？
- 备份是否加密？备份密钥存放在哪里？
- 设备是否有全盘加密、最新补丁和受限扩展？
- 是否定期更换高价值密码？
写到这里我又想到一点：很多人把“方便”放在第一位，结果把安全放到第二。其实稍微多花一点时间设置主密码、启用MFA和选择合适的同步选项，就能把被动等待泄露变成主动防护——这是成本很低但效果成倍率提高的事情。好了，就先写到这儿，回头还有些实现细节想补，但差不多能用了。