简而言之,与常规密码管理器相比,此方法几乎没有提供额外的安全性(甚至可能降低安全性,具体取决于实现),并且存在一些使其不切实际的可用性问题。
安全
让我们以您的恶意软件示例为例,该恶意软件使用键盘记录器获取您的主密码,然后破坏密码文件中的所有密码。您提出的方案没有提供针对该攻击的额外保护:如果您的主密码通过键盘记录器被盗,则攻击者拥有您所有服务的所有密码。(这里甚至不需要窃取数据库,只需主密码。)
您提到的另一个威胁是密码管理器的开发人员通过更新他们的密码管理器来窃取您的主密码或解密的密码数据库,从而危及您的安全。您的方案也无法减轻这种威胁,因为您用来生成密码哈希的程序的开发人员也可以这样做。(我假设您没有编写自己的哈希工具。这似乎与编写自己的密码管理器一样不方便且容易出错。)
您还提到了基于云的密码管理器知道您何时访问密码的隐私问题。虽然您提出的方案可以减轻这种威胁,但也可以通过传统的密码管理器来缓解这种威胁,方法是始终将密码数据库的副本同步到每个本地设备并在查找密码时引用该文件,或者只需完全存储您的密码数据库离线。例如,KeePass 支持这两种方法。
最后,该计划还面临另一个威胁。它允许您注册的任何站点,或任何获得此类站点密码数据库的攻击者,对您的主密码进行无限次数的离线暴力破解尝试。这可以通过使用强主密码和慢速哈希算法来缓解,但这仍然是一个值得考虑的问题。您也可以通过在散列算法中包含辣椒来缓解它,但是您会因为要求用户访问包含辣椒的文件来获取他们的密码而失去了所提出方案的主要好处。
可用性
至于可用性,正如您所指出的,该方案确实具有不需要用户跟踪密码数据库的好处。但是,我认为该方案存在一些可用性问题,我认为这些问题大大超过了这一优势。
第一个是,如果您的特定服务的密码被泄露(例如,一个网站以明文形式存储他们的密码并且他们的数据库被盗,或者密码在传输过程中通过中间人攻击被盗),您将没有简单的方法更改该服务的密码而不更改所有其他帐户的密码(例如,通过更改主密码)。您可以向哈希生成器添加一个附加参数,例如递增数字,以允许更改密码,但是您必须为每个服务记住这个数字,这很不方便。
同样,如果由于某种原因您的主密码被泄露,此方案会使更改该密码变得相当困难,因为您不仅必须在您拥有帐户的每个站点上更改密码,而且您还必须记住您拥有的每个站点一个帐户,以确保您在更改密码时不会错过任何一个 - 没有像密码管理器那样方便地列出所有这些网站。
另一个不太明显的可用性问题,但根据我在密码管理器方面的经验,我相信这个方案可能会遇到,你访问的每个站点的“名称”并不总是很明显。您可能认为您可以将每个站点的域名插入您的哈希算法并将其用作站点名称,但实际上并非总是如此。作为一个简单的示例,请考虑这个站点,Information Security Stack Exchange。假设您选择对该站点使用基于密码的登录,而不是通过 Google 或 Facebook 等第三方联合登录,那么您在方案中使用什么作为站点名称?security.stackexchange.com
? stackexchange.com
?stackoverflow.com
? 所有这些域都使用相同的登录名。一旦你选择了使用哪个名字,你就必须记住它。其他网站可能会使这一点变得不那么明显,例如 gamepedia.com,它要求您使用您的“诅咒社区”帐户登录,该帐户在该公司制作的多个网站之间共享。
最后,这个方案最重要的可用性问题可能是具有限制性密码要求的网站。如果一个站点要求您的密码包含特殊字符,而另一个站点要求您只使用字母数字字符怎么办?您可以在散列方案中添加选项以适应这些要求,但现在您必须记住并记住每个站点的密码要求,只要您想登录。
TL;博士
虽然您提出的方法确实解决了一些问题,但它也会产生其他问题,并且不提供任何额外的安全性。
安全:
- N/A:不能防御恶意软件
- N/A:不能防止密码管理软件的恶意开发者
- N/A:不提供现有密码管理器无法提供的任何隐私保护
- 缺点:将主密码暴露给来自恶意网站和黑客的暴力攻击
可用性:
- Pro:使用户不必管理密码数据库文件
- 缺点:更改特定于站点的密码需要记住其他特定于站点的信息
- 缺点:更改主密码不方便
- 缺点:使用哪个站点名称作为哈希函数的输入并不总是很明显
- 缺点:管理具有限制性密码要求的网站非常困难