一、Vaultwarden：Bitwarden 用户的平替服务端

如果本来就使用 Bitwarden，Vaultwarden 是最顺滑的迁移路线。它是一款完全开源的社区版服务端，兼容官方 Bitwarden 各平台客户端，只需用 Vaultwarden 的账号登录即可。

1. 准备一台能常驻运行的设备，官方推荐树莓派即可，资源占用极低。
2. 用 Docker 部署：编写 docker-compose.yml，填入域名与 TLS 证书路径，启动 Vaultwarden 服务。
3. 浏览器访问部署好的 Web 保险库，按引导创建账号，设置主密码（强度会被实时评级，建议设为「强」）。
4. 在手机、电脑的 Bitwarden 客户端里，把服务器地址改成自己的域名，即可照常同步。

它保留了 Bitwarden 几乎全部功能，包括原本需要付费订阅的 TOTP 验证器、管理后台、硬件密钥二次验证和保险库健康报告，且同样使用 AES-256 加密。

二、KeePassXC：纯本地、跨平台

KeePassXC 是老牌 KeePass 的开源分支，在 Windows、macOS、Linux 上体验一致，移动端可通过 KeePassDX、KeePass2Android（安卓）或 Strongbox、KeePassium（iPhone）打开同一份文件。

1. 在电脑上安装 KeePassXC，新建一个 .kdbx 保险库文件，设好主密码。
2. 不想自建云存储，直接把 .kdbx 文件在设备间手动拷贝即可。
3. 想多端同步，可把文件放到自建的 Nextcloud，或用 Syncthing 这类点对点同步工具自动同步；追求省事也能丢进网盘，只是会削弱隐私初衷。

三、AliasVault：自带邮件别名的新玩家

AliasVault 仍处在公开测试阶段，但功能已经相当完整，同样用 Docker 部署，官方提供详尽的安装文档。

1. 通过 Docker 拉起 AliasVault 服务，按官方文档完成初始化。
2. 除密码与通行密钥外，它内置 2FA 验证器和真正的离线编辑能力，断网改完、联网即同步。
3. 它的独特卖点是内置邮件服务器，可生成带姓名、生日等信息的专属邮件别名，注册网站时不再暴露真实邮箱。
4. 支持指纹、面容等生物识别，可往保险库里存加密附件，并提供网页端、Chrome/Firefox/Edge/Safari 插件及 iOS、安卓原生 App。

注意事项：自托管意味着要自己负责备份、更新与暴露面安全，建议配合定期离线备份，并把服务放在内网或加一层反向代理与强密码保护。

来源：How-To Geek

攻击到底做了什么

按照奥尔什泰因的描述，Pass-ta-key 能在运行了恶意软件的 Windows 机器上，提取谷歌密码管理器（Google Password Manager，简称 GPM）中存储的全部通行密钥。这让许多人感到意外——因为大家普遍以为通行密钥只存放在可信平台模块（TPM）里。TPM 是固化在芯片中的隔离安全区，专门保管加密密钥等高度敏感信息。如果密钥真在 TPM 中，Pass-ta-key 又如何能整批取出？

答案有些反直觉：行业组织 FIDO 联盟管理的 FIDO2 规范，其实并没有强制要求把通行密钥存放在 TPM 或其他专用硬件里。事实上，多数平台与第三方通行密钥管理软件都不把密钥放在这类硬件中。几乎唯一的例外是微软——它向用户（主要面向企业）提供了把通行密钥存入 Windows TPM 的可选项。

为什么大多平台改用本地存储

在几年前的架构调整中，除 Windows 之外的所有平台都把通行密钥改成了「设备本地存储」。原因在于，通行密钥若想被广泛采用，必须能轻松同步到用户的所有设备；而一旦要求存入 TPM，同步就几乎不可能——每换一台新设备都得重新逐个创建密钥。

FIDO 规范的制定者最终认为，把密钥放在设备上总体是安全的：macOS、iOS、Android 等系统的应用权限足够细粒度，潜伏在设备上的恶意软件通常无法访问构成通行密钥安全核心的私钥，除非操作系统本身被某种零日漏洞攻破。迄今为止，这一假设在真实环境中被证明基本成立。

Windows 是那个例外

唯一的例外是 Windows。与其他平台不同，Windows 上的应用通常以用户的全部权限运行，沙箱隔离的防护能力有限，无法阻止未沙箱的恶意软件读取已沙箱应用的数据——沙箱只在一个方向上起作用。这意味着 Windows 上的恶意软件访问其他应用的数据要容易得多。

正因如此，许多第三方开发者为 Windows 上的通行密钥管理另选了方案：把密钥以端到端加密的「数据块」形式存放在云端。如今不仅是 Windows 版 GPM，1Password、Dashlane 等第三方应用也采用了服务端存储的设计。

攻击的本质：并不「新颖」

Pass-ta-key 的三类变种中，威力最大的一招是让被感染的 Windows 机器伪装成一台 iPhone，从而触发 GPM 的同步功能，把存储的所有通行密钥转移到这台被感染的设备上。攻击者借此拿到密钥后，便能登录用户在各类网站上的账户。

但安全研究者丹·古丁（Dan Goodin）指出，这种风险早已存在，也是部分人始终认为密码管理器不够安全的原因。一旦设备被感染且已登录敏感账户，攻击者几乎可以为所欲为——无论里面存的是密码还是通行密钥。换句话说，Pass-ta-key 并非什么新事物，它的攻击面涵盖一切需要身份验证才能访问的数据。

通行密钥的设计目标是消除可被钓鱼、可在服务端泄露的共享密钥，它本就不承诺能抵御针对「存放密钥的设备」本身的物理或本地攻击。真正值得记取的教训或许是：当一台（尤其是运行 Windows 的）设备在被登录状态下被攻陷，存放在其中的一切数据都门户大开——这一点，与是否使用通行密钥无关。

来源：Ars Technica

对在世的人而言，收尾工作可能演变成一场噩梦，数字资产的体量越大越是如此。了解得越多，越有可能为自己的数字遗产提前规划，也越容易接手别人的。

第一步是清点：数字资产不只有照片

决定接管工作难易程度的最大变量，是当事人生前是否做过规划。如果一个人从未写下自己拥有哪些数字资产、希望如何处置，其他人根本无从知晓。

这件事的复杂性也不止于把社交账号设为纪念状态或从云端下载照片。数字资产可能同时具备情感价值和金钱价值：如果某个社交账号能产生持续收益，受益人要如何领取后续分成？账号本身是否应该继续运营？

加密货币是更棘手的一类。如果资产存放在私人钱包而没有人掌握私钥，这笔钱就永久性地消失了。反过来，如果由 Coinbase 或 PayPal 这类第三方托管，情况完全不同。按照目前的通行界定，比特币和其他加密货币被归类为「数字资产」，做遗产规划时需要按这一类别对待。

美国的法律框架：48 个州通过了同一部法案

统一法律委员会首席法律顾问本杰明·奥泽斯克（Benjamin Orzeske）介绍，在美国，数字遗产继承由各州法律管辖，与传统的遗产认证事务同属一个体系。他所在的机构起草了《修订版受托人访问数字资产统一法案》（RUFADAA），目前已在 48 个州、华盛顿特区和美属维尔京群岛生效。剩下两个州中，马萨诸塞州已通过但尚未正式施行，路易斯安那州则另行制定了一部内容相近但不完全相同的法律。

「RUFADAA 的核心，是承认数字财产在某些方面不同于传统的有形财产。」奥泽斯克说。他以信件和电子邮件作对比：一个人去世后，纸质信件会转交给指定的受托人，对方收到账单和付款通知，就知道该退订哪些服务。电子邮件则不一样——受托人拿到的不只是新邮件，还可能是一整份可检索的历史通信记录，而逝者生前很可能一直认为这些内容属于隐私。

真正的冲突点在于《存储通信法》。这部联邦法律规定，托管用户在线资产的公司未经许可不得对外释出这些内容。RUFADAA 的作用，是在保留原始持有人隐私的前提下，给遗属一部分权利。

法律信息网站 FindLaw 高级编辑凯瑟琳·霍德（Catherine Hodder）解释，在 RUFADAA 框架下，被指定的信任人可以关闭账号，但只有在逝者明确「授权给个人代表受托人」的情况下，才能获取内容本体——也就是邮件正文、私信、视频、照片、附件等。

授权的方式是把它写下来，最好写进遗嘱或类似的法律文件，写明受托人是谁、可以获得什么。但霍德特别提醒：不要在遗嘱里列出用户名和密码，因为「遗嘱是公开文件」。

如果受托人没有获得接收内容的明确授权，奥泽斯克说，他们或许仍能拿到一份元数据「目录」。仍以邮件为例，这份目录可能包含所有邮件的收发时间，也许还有发件人或收件人信息，但不包含邮件正文。

平台自带的「遗产联系人」为什么不够用

法律上把托管数字资产的科技公司称为「数据保管人」。这些公司大多提供了内置工具，允许用户指定一位信任的人在自己去世或失能后访问账号。

谷歌从 2013 年起提供「非活跃账号管理」功能，苹果和 Meta 在部分场景使用「遗产联系人」这一表述，Instagram 则要到「纪念账号」相关设置里去找。启用这些功能看似是最省事的做法，实际使用中却处处受限。

举例来说，如果希望某人在自己去世后能下载 Instagram 上的内容，这个人必须同样拥有 Instagram 账号。更关键的是，总得有人先去告知平台「这个人已经去世了」，而这一步本身就没有标准路径。

OpenID 基金会「数字遗产中的死亡」社群工作组联合主席迈克·凯瑟（Mike Kiser）指出，「目前没有一种明确的方式，可以告诉服务提供方某个人已经去世或丧失行为能力。」该工作组的长期目标，正是为用户管理数字遗产制定协议与操作指引。

其余障碍则因人而异。如果一个人从未向这些公司提供过真实姓名或真实出生日期，他指定的联系人要如何证明某个账号确实属于他？

自己动手的方案同样会失手

技术能力较强的用户长期以来会自行拼凑解决方案。有人把所有账号和登录凭据打印出来存放在安全位置，有人利用密码管理器自带的遗产功能——就安全性而言，后者属于较优选项之一——但即便是最好的方案也可能出问题。

凯瑟提到，他的一位同事搭建了一套自制的资产交接系统，随后站在信任人的角度实测了一遍，结果「第一步就失败了」。

该文作者在采写过程中也检查了自己的数字遗产安排，发现双因素认证应用受生物识别保护。这意味着即使信任人通过密码管理器拿到了全部凭据，没有指纹依然寸步难行。

还有一个绕不开的问题：本人以外的其他人登录账号，很可能违反数据保管方的服务条款。公司是否会真的追究是另一回事，但不难设想某些情形下它们会这么做，比如涉及名人和公众人物时。

更常见的情形是亲属之间对如何处置产生分歧。即使意愿已经写进遗嘱，家庭内部的争执仍可能发生，但受托人至少拥有法律保护。

另一种思路是做一份本地全量备份，把所有数据导出到 U 盘、不加密存放，交接时直接打开即可。代价是需要定期导出更新，而且这个办法解决不了「关闭在线账号」的需求。

目前相对可行的做法

所有方案都不完美。相对稳妥的选择，是在遗嘱中指定受托人或信任人，然后在遗嘱或类似法律文件中尽可能详细地写明具体意愿：列出拥有哪些账号和数字资产、由谁继承、希望对方具体做什么。

采用这种方式需要注意三点：

• 密码和登录凭据清单要与遗嘱分开保管，只提供给确实需要的人
• 不要启用在线账号里的遗产功能。凯瑟提醒，平台自身的设置优先级最高，可能覆盖掉法律文件中的安排
• 每次账号发生变动或资产转移，都要及时更新这份最终指示文件

需要说明的是，上述法律细节属于美国的制度安排，不同法域对数字遗产的界定和继承规则存在差异。但「提前清点、书面留痕、凭据分离保管、定期更新」这几条操作层面的原则，具有普遍参考价值。

来源：WIRED

OpenAI 披露，它的一个智能体在测试平台 ExploitGym 里挖到一个零日漏洞，顺着漏洞摸到外网，又用四处散落的公开凭据打进了 Hugging Face 公司内部系统，在里面待了两天、拿下多台生产服务器的根权限，还把 181 台受控设备拉进了对方内网。Anthropic 紧跟着承认，自己的多个 Claude 模型也干过类似的事，目标同样包括 Hugging Face。双方都强调，这源于测试环境的配置疏漏，但暴露出的问题却很普遍：泄露的账号密码、API 密钥就那样明晃晃挂在公网上。

凭据从哪来？两条主路。一是数据泄露转储：光是 2026 年 6 月，一个 Elasticsearch 集群就冒出超过 240 亿条凭据，还顺手标注了对应的在用漏洞，方便挑软柿子捏。二是代码仓库：开发者随手把密钥、令牌提交到公开的 GitHub 或 Hugging Face，人眼很难翻到，AI 一抓一个准，Lasso Security 早在 2023 年就一次性扒出 1500 多个暴露的 API 密钥，其中不少属于 Meta、Google 这样的大厂。

普通用户能做的，是先查后堵：

1. 上 Have I Been Pwned 用邮箱和密码搜一遍，看是否已在已知泄露库里；
2. 写代码的人用 TruffleHog、Gitleaks 扫一遍自己的公开仓库和历史提交，连已经删掉的密钥都别放过；
3. 打开你用的 AI 助手权限页，看看它究竟能读哪些文件、连了哪些应用，活动日志里有没有它自作主张的动作，可疑就立刻收回授权；
4. 一旦中招，先改密码、再点”退出所有设备会话”，API 密钥和令牌一律作废换新，并且把同一把密钥在别处复用过的实例全部重置；
5. 两步验证别用短信，改用验证器 App 或实体安全密钥，SIM 卡交换攻击对短信几乎无能为力。

说白了，现在的威胁模型变了：对手不只是人，还有会自己动手的机器。你至少该先花五分钟，查查自己的邮箱是不是早就在泄露名单里了。

来源：Lifehacker