分享两篇文章：开源密码管理器更安全吗？

第二篇文章中“密码管理器存储主密码”是个词不达意的错误翻译。
原文相关段落：
Some applications stored the entered master password in plaintext or implemented hard-coded crypto keys in the program code. Consequently, attackers can easily circumvent the crypto algorithm altogether and thereby gain access to all of the user’s data.
很显然如何存储和访问都有更明确的限定。

不过，TeamSIK 的这个说法也是有问题的。
现实中最显著不安全因素来自用户对系统错误的安全假设，而替用户定义什么叫 security 是造成这个现象的原因之一。
具体来说，原文中隐含假定理想的密码管理器总是应当且能够保证不泄漏敏感信息，给用户以错觉认为密码管理器能提供保密保证，然而这就是体系上的重要潜在漏洞——仅仅是方便方案提供者甩锅而无助于实际确保安全性。另一个更常见的可比的例子是鉴权者无原则要求强口令的密钥策略，导致不少用户倾向于以不安全的方式另行储存密码，凭空增加攻击侧信道，反而引起更大的风险（讽刺的是，密码管理器在一定程度上就是为了应对这种问题而被发明的）。

安全系统想要达到的一个主要根本目标是：让理解安全的用户得到预期的安全属性。获取用户数据并不总破坏这种属性，例如考虑用户可以极低成本地有意投毒而愚弄攻击者。
当然，极端的安全系统玩家可以不在乎这种密码管理器的限制问题（若有，也可以自己实现密码管理器，这至少发明现实可靠的加密算法容易得多）。而对大多数密码管理器的用户，他们仅仅需要一种把密钥视为最需要避免泄密的数据而容易访问的方案。但这个意义上，如何存储主密码也不是什么大不了的问题了——尽管用明文、硬编码加密的代码和真正的密码(cipher)具有密码学强度上的显著不同，攻击者一旦获知主密码就可以访问所有敏感数据的这点不会有差异——注意主密码可以被密码管理器“存储”阶段前截获。要修补这里的缺陷，需要用 2FA 等方式代替单一的固定口令。不过，这又增加了使用的困难，削弱易用性和灵活性，而在另一方面同样可能增加前述的风险。
作为实用解决方案，密码管理器应当把容易做的事情做好，而不是妄图面面俱到。这个意义下，花费较小的代价而明确减少显著的风险的设计是“好”的——包括避免使用明文存储主密码。但是，鉴于密码管理器不是入侵检测系统也不需要实现访问权限控制，它的“管理”行为并没有在字面上必须提供对主密码的反泄密存储保护（作为和用户的接口约定），即便退到这个地步，不合理的主密码存储方案仍然是个实现质量(QoI) 问题，而不是所谓的 security vulnerability 。真正的漏洞直至用户错误地信任密码管理器会提供这种保密才会形成——尽管这种错误信任非常普遍，远甚于这里强调的对开源密码管理器的无原则的信任。

另一个更现实的例子是 Chrome 通过明文保存密码： https://www.v2ex.com/t/872745 。这里，Chrome 的实现也不算是严格的安全漏洞，因为一个应用程序假定一个多用户宿主系统提供正确实现的访问控制是合理的，对文件系统的访问控制的正确实现是宿主系统的职责，正确利用系统提供的访问控制排除非预期访问是用户的职责，两者都不是 Chrome 需要关心的本职工作，所以 Chrome 的维护者的确有理由拒绝承认这是功能缺陷。但是，无论是宿主实现的安全性不可保证（乃至不可审计），还是用户普遍缺乏安全意识的现实，都使不确定的攻击更容易实现，因此这里的 QoI 问题相比 Firefox 等替代，无疑是足够显著的了。

@FrankHB
👍，看得很仔细了。感谢你提供一个很好的角度。

用户是否重视数据安全，主密码是否会因用户个人原因而泄露，那确实是密码管理器厂商无法控制的。单从安全的角度来看，密码管理器厂商应该尽可能地提升产品的安全设计，如果存储主密码，那无疑是又增加了一个可能泄露主密码的途径，内部坏员工或是黑客都有可能会从服务器上偷取。

密码管理器厂商可能会基于各种各样的原因而保存主密码，甚至像 Chrome 那样明文保存密码，无可否认的是，这样做确实降低了安全性。加密存储总比明文存储更安全，不存储主密码总比存主密码更安全。

我们文章也只是讨论安全设计，分析潜在的安全风险，不深究各种做法有何优劣噢。