基于浏览器的密码管理器安全性评估

阅读量324198

|评论1

|

发布时间 : 2020-11-03 10:00:53

x
译文声明

本文是翻译文章,文章原作者 Sean Oesch,Scott Ruoti,文章来源:usenix.org

原文地址:https://www.usenix.org/conference/usenixsecurity20/presentation/oesch

译文仅供参考,具体内容表达以及含义原文为准。

 

密码管理器可以帮助用户更有效地管理其密码,并解决围绕基于密码的身份验证的许多问题。先前的研究已经发现了现有密码管理器中的重大漏洞,特别是在基于浏览器的密码管理器中,本文评估了十三种流行的密码管理器,并考虑了密码管理器生命周期的所有三个阶段(密码生成,存储和自动填充)。本文的评估是对密码管理器中密码生成的首次分析,它发现了几种非随机字符分布,并确定了所生成的密码容易受到在线和离线猜测攻击的实例。对于密码存储和自动填充,密码管理器在过去的十年中有所改进,但仍然存在很多问题。这些问题包括未加密的元数据,不安全的默认值以及点击劫持攻击的漏洞。根据结果确定了需要避免使用的密码管理器,并提供有关如何改进现有密码管理器的建议。

 

0x01 Abstract

尽管基于密码的身份验证面临着公认的问题,但它仍然是Web上使用的主要身份验证形式。由于攻击者难以猜出的密码也很难被用户记住,因此用户通常会创建较弱的密码以避免回想它们的认知负担。实际上,随着用户需要存储的密码数量的增加,他们经常在网站之间重复使用密码。

密码管理器可以帮助用户更有效地管理其密码。它们通过生成强密码,存储这些密码,然后在访问站点时填写适当的密码来减轻用户的认知负担。用户现在可以遵循有关密码的最新安全建议,而不会给自己造成很大的认知负担。但是密码管理器并非不受攻击。 之前在LastPass和RoboForm等主要密码管理器中发现了重大漏洞,由于基于浏览器的密码管理器的密码自动填充功能,容易遭受跨站点脚本攻击(XSS)和网络注入攻击。

部分研究已经过去了五年或五年以上,因此尚不清楚密码管理器是否仍然易受攻击,或者现在是否准备好被广泛采用。为了回答这个问题,本研究更新并扩展了以前的结果,并提供了对十三种流行密码管理器的全面,最新的安全性评估,包括五个浏览器插件和六个直接集成到浏览器中的密码管理器。

在评估中,考虑了完整的密码管理器生命周期-密码生成,存储和自动填充。对于密码生成,评估了由研究过的密码管理器生成的1.47亿个密码的语料库,以确定它们是否表现出攻击者可以利用的任何非随机性。结果发现了生成密码的几个问题,最严重的是,一小部分较短的生成密码难以抵抗在线和离线攻击(分别少于10个字符和18个字符)。

结果发现,尽管密码管理器在过去五年中得到了改进,但仍然存在重大的安全隐患。在本文的结尾提出了一些建议,包括如何改进现有的密码管理器以及确定将来可以显着提高密码管理器的安全性和可用性的未来工作。

 

0x02 Password Managers

从最基本的意义上讲,密码管理器是一种存储用户凭据(即用户名和密码)的工具,可减轻与用户记住许多唯一登录凭据有关的认知负担。这种密码存储库通常称为密码库。理想情况下,保管库本身以加密形式存储,其中加密密钥最常见地是从用户选择的密码(称为主密码)派生的。密码库可以在线存储,从而使其可以在多个设备之间同步。

除了存储用户选择的密码外,大多数现代密码管理器还可以帮助用户生成密码。密码生成将所需密码的长度,所需字符集以及密码应显示的任何特殊属性作为输入(例如,至少一位数字和一个符号,不难识别的字符)。密码生成器输出符合输入标准的随机生成的密码。

许多密码管理器还可以通过自动选择并填写(即自动填写)适当的用户名和密码来帮助用户对网站进行身份验证。如果用户在网站上拥有多个帐户,则密码管理器将允许用户选择他们希望用于自动填充的帐户。如果正确实施和使用,密码管理器将为用户带来许多明显的好处:

1.它减轻了记住用户名和密码的认知负担。

2.为每个网站分配不同的密码很容易,解决了密码重用的问题。

3.易于生成可抵抗在线和离线猜测攻击的密码。

 

0x03 Analysis

在本文中分析了13种不同的密码管理器,可以根据它们与浏览器的集成程度将其分类:应用程序,扩展程序和浏览器。本文专注于浏览器中的密码管理器,但包括两个桌面客户端进行比较,应用程序是未与浏览器集成的桌面客户端。基于扩展的密码管理器被部署为浏览器插件,并且不依赖于桌面应用程序。基于浏览器的密码管理器是作为浏览器一部分实现的本机组件。

上表给出了分析后的密码管理器按这些类别细分的情况。该表还报告了与实用程序和可用性相关的功能-支持密码生成和自动填充,支持使用云同步扩展设置和密码库,使用密码的功能。命令行界面的密码管理器以及安全性-该工具是否支持多因素身份验证(MFA),是否可以锁定密码库,是否必须在其自己的选项卡或应用程序上输入该库的主密码(为防止此对话框的欺骗),密码管理器是否提供了一种工具来评估存储的帐户和密码的安全性,密码复制后管理器是否从剪贴板中清除了密码以及该工具是否开放源代码。

1)基于应用

分析了基于应用程序的密码管理器,倾向于手动同步以提高安全性。

KeePassX(v2.0.3):KeePass是基于应用程序的密码管理器,最初是使用.NET平台构建的,并且旨在在Windows上使用。 KeePassX是KeePass的跨平台端口,用QTframework替代了.NET平台。

KeePassXC(v2.3.4):KeePassXC是KeePassXintended的一个分支,旨在提供更频繁的更新和KeePass或KeePassX中找不到的其他功能(例如,用于密码生成的更多选项,命令行界面)。KeePassXC还提供了一个与应用程序接口的浏览器扩展程序,以在浏览器中自动填充密码。总体而言,KeePass系列应用程序估计有2000万用户。

2)基于插件

扩展程序缺少清除剪贴板的权限,基于扩展程序的密码管理器的sonone支持此功能,从而使用户密码容易受到无限期访问剪贴板的任何应用程序的攻击。分析的所有扩展都不支持该扩展本身的同步设置,要求用户记住正确更新这些设置以匹配其设置的每个新设备的安全性首选项。这些扩展设置包括对安全至关重要的选项,例如是否在关闭浏览器时注销,是否使用自动填充以及是否在填写不安全的表单之前发出警告。每个基于扩展的密码管理器的用户体验基本相似。

1Password X(v1.14.1):1Password估计有1500万用户,1Password提供基于应用程序的客户端(1Password)和基于扩展的客户端(1Password X);在本文中评估了基于扩展的客户端,因为如果需要与浏览器集成(推荐大多数用户都希望这样做),它是推荐的工具。虽然两个系统的安全性相似,但还是有一些小的区别—例如,从应用程序中的剪贴板中清除了密码,但未从扩展中清除。 要最初从云下载密码库,必须输入在用户生成帐户时提供给用户的128位密钥,从而为基于云的密码库提供了额外的安全性。

Bitwarden(v1.38.0):在分析的基于扩展的密码管理器中,Bitwarden是独一无二的,因为它的所有功能都可用于非付费帐户,而其他密码管理器则需要订阅才能访问某些功能。

Dashlane(v6.1908.3): Dashlane估计有1000万用户。除了存储每个网站的用户名和密码外,Dashlane还在每个站点上跟踪和同步以下三个设置:“always log me in”,“always require [the master password]”,和 “Use [password] for this subdomain only.” 与不同步任何扩展设置的其他基于扩展的密码管理器相比,此功能提供了一点优势。

LastPass(v4.24.0):LastPass估计有1650万用户,是所有商业密码管理器中最多的。

RoboForm(v8.5.6.6): RoboForm估计有600万用户。像1Password一样,RoboForm同时提供基于应用程序的客户端和基于扩展的客户端。在本文中,出于与使用1Password X采取此方法相同的原因,评估了基于扩展的客户端。

3)基于浏览器

与基于应用程序的密码管理器和基于扩展的密码管理器相比,基于浏览器的密码管理器缺少许多功能。虽然所有基于浏览器的密码管理器都允许使用多因素身份验证来保护存储密码库的云帐户,但除了Firefox之外,其他任何人都可以锁定该库,而无需从浏览器中删除该帐户。 Firefox提供了使用主密码来限制对密码库的访问的选项。由于这些密码管理器没有同步设置,也永远不会将密码复制到剪贴板,因此这些功能不适用。

Chrome(v71.0):Chrome支持生成密码。它检测用户何时可能需要密码,并提供要为该用户生成密码的信息。与其他任何密码管理器不同,Chrome具有基本功能来尝试检测密码策略。

Edge(v42.17134)、Firefox(v64.0)、 Internet Explorer(v11.523)、Opera(v58.0.3135):这些密码管理器在高级功能上都相似。

Safari(v12.0):Safari与iCloud钥匙串集成时可以生成密码,尽管这些密码始终为“ xxx-xxx-xxx-xxx”形式。

4)密码管理器更新

自从进行研究以来,几个密码管理器进行了一些较小的更改:(1)KeePassXC已过渡到使用Argon2D作为其默认密钥派生功能,(2)LastPass更新了其密码生成界面,删除了选择,(3)RoboForm更新了他们的密码生成界面,删除了选择数字位数的选项,并将默认密码长度增加到16。本研究也意识到了即将出现的一些重要变化:Firefox将过渡到使用Firefox Lockbox作为其默认密码管理器,andEdge将过渡到在Chromium项目之上构建。

 

0x04 Password Generation

密码生成是密码管理器生命周期中的第一步。在评估的13个密码管理器中,有七个完全支持密码生成(KeePassX,KeePassXC,1Password X,Bitwarden,Dashlane,LastPass和Roboform),另外两个则部分支持Chrome和Safari。为了提供比较密码管理器的基准们编写了一个python脚本,该脚本使用/dev/random和在线SecurePassword Generator(SPG)生成密码,这是在Google上搜索“密码生成器”时的第一个搜索结果。

1)设置和功能

上表总结了每个测试工具的配置选项,默认设置和功能。尽管可以在KeePassX,KeePassXC和LastPass中将其关闭,但所有密码管理器都支持确保每个选定字符集中至少包含一个字符。除基于浏览器的密码管理器外,所有密码管理器还具有避免生成包含用户难以阅读和/或记忆的字符(例如,难以发音,看起来与另一个字符相似)的密码的选项。删除的字符在密码管理器之间不一致。

虽然所有密码管理器都支持相同的字母和数字集([A-Za-z0-9]),但是它们各自具有不同的符号集。KeePassXC具有最大的符号集,支持所有标准ASCII符号(空格除外)并支持扩展的ASCII符号集。 KeePassX和Dashlane还支持标准ASCII符号(空格除外),但不支持扩展的ASCII符号集。 1Password支持刚好超过一半的ASCII符号(19个符号),而其他系统则支持8个或更少的符号。不出所料,限制符号集对生成密码的强度有很大影响,本文稍后将讨论其含义。

在大多数密码管理器中,常见的一个问题是它们将上次使用的设置保存为新的默认设置。虽然这似乎是针对可用性的功能,但它可能会导致用户在生成密码时使用的设置少于最佳设置。通常,用户更改密码生成设置有两个原因:(1)建立安全的默认设置,(2)生成符合弱于默认设置的策略的密码。

在后一种情况下,较新的,较弱的设置将替换较旧的,较强的设置作为新的默认设置。尽管用户可以手动恢复其更安全的设置,但不能保证他们会这样做。 Dashlane采取了一种最佳方法,即不自动保存最新设置,而是为用户提供覆盖当前默认设置的选项。 KeePassX采用了一种中间方法,将新设置保存为以后生成的密码,直到应用程序关闭并再次打开。

2)密码收集与分析

为了评估由密码管理器生成的密码的质量,首先从每个密码管理器收集了大量生成的密码。使用多种方法来生成密码:现有的命令行界面(Bitwarden,本文的python工具),修改源代码以添加命令行界面(Chrome,KeePassX,KeyyPassXC)或使用Selenium(1Password X,Dashlane,LastPass) ,RoboForm)。无法分析Safari的密码,因为它没有任何脚本来生成密码脚本,尽管确实手动生成并分析了100个密码以检查是否有明显的问题并且没有检测到任何问题。

生成由字符类(字母(l),字母和数字(ld),字母和符号(ls),符号和数字(sd))以及所有四个类(全部)和密码长度(8、12,和20个字符长-为了确定这些选项是否对生成的密码的随机性有影响。默认情况下,大多数工具都要求生成的密码在每个字符集中都包含一个字符,只有Chrome,KeePassX,KeePassXC和本研究的python工具未启用此选项。对于每个密码管理器,字符类和密码长度,生成了100万个密码,但1Password X除外,后者不允许生成仅包含符号和数字的密码。这产生了1.47亿个密码的语料库(10×5×3—3)。

收集此数据集后,分析了其随机性和可猜测性的质量项。没有已知的方法可以证明伪随机生成器与随机生成是无法区分的,因此采用了多种分析技术,每种技术都试图找到非随机行为的证据:Shannon熵,χ2随机性检验,zxcbvn密码分析工具,以及基于递归神经网络的密码猜测器。

Shannon熵用于检查每个产生的字符(不是密码)的频率是否异常。集合的Shannon熵是对根据符号出现频率对一串符号进行编码所需的平均最小位数的度量。计算为∑i pi logb(pi)。虽然Shannon熵是衡量用户选择密码的一种不好方法,但它对于评估随机密码的相对强度很有用。Shannon熵不受密码长度的影响,仅受密码中可以出现的不同字符数的影响。字符串及其在语料库中的相对频率。

随机性的χ2检验是一种简单的统计检验,用于确定两个分布之间的差异是否可以通过随机机会来解释。使用χ2检验来独立评估每个密码集,并使用Bonferonni correction修正了p值,以说明同一家族的多项统计检验。

zxcbvn工具用于检测可能存在于密码中的字典单词和简单模式,这两种都是非随机性的潜在示例。 zxcbvn还估计了密码破解者破解密码所需的猜测次数,使用它来了解密码是否可以抵抗在线和离线猜测。

为了检测生成的密码是否比zxcvbn可以检测到的密码更微妙,使用了构建的神经网络密码猜测器。该猜测器使用长短期记忆(LSTM)递归神经网络(RNN)架构,根据训练集构建密码猜测器。作为输出,它将产生经过蒙特卡洛估计的经过训练的密码猜测器猜测测试集中的密码所花费的时间。对于每个密码语料库,使用80%的密码来训练神经网络,并针对20%的密码进行了测试。由于猜测器的问题,只能测试长度为8和12的密码,因为无论使用什么设置,长度为20的密码都会因内存不足异常而崩溃。

尽管zxbcvn和递归神经网络都用于评估生成的密码中的随机性质量,但它们也可以用来估算在线或离线猜测攻击尝试使用该密码所需的猜测次数。需要超过10^6个猜测的密码被认为具有抵御在线攻击的能力,并且需要超过10^14个猜测的密码被认为具有抗离线猜测的能力。使用此猜测计数,能够分析密码管理器是否正在生成容易受到这些攻击的密码。

3)结果

密码强度:对生成的密码的分析发现,几乎所有长度为12及更长的密码都足够强大,可以抵御在线和离线猜测攻击(见上图c和上图d)。尽管如此,并不是所有的密码管理者都可以创建强度相同的密码,这些微小的扰动会对长度8的密码百分比产生重大影响,这些百分比可以安全地防止离线猜测攻击(几乎所有人都可以防止在线猜测攻击)(见上图a和上图b)。这些强度上的差异在很大程度上可以由每个密码管理器使用的字符集类的不同组成来解释。尽管在考虑符号时差异最为明显,但多个密码管理器还限制了可用的字母和数字(例如,由于相似性而删除了“ 0”和“ O”)。查看字符频率,还发现Dashlane使用一组不同的字母,具体取决于密码的长度。目前尚不清楚Dashlane为何表现出这种行为。

随机性:χ2测试在生成的密码中发现了一些非随机行为的实例(上表)。除一个非随机字符频率分布外,所有特征都可以用一个功能来解释-要求密码每个字符集中至少有一个字符。如果未启用此功能,则任何给定字符将出现在密码中的可能性与密码的长度以及所有启用的字符集中的字符数成正比(参见公式1)。启用此功能后,概率也与该字符集中的字符数成正比(参见公式2),从而导致来自较小字符集(例如,数字,符号)的字符的字符频率更高,这说明了通过χ2检验检测均匀性。注意到,有可能对此偏斜进行调整并保持均匀分布,尽管不进行校正不会产生明显的安全影响。

尽管Bitwarden(sd)和Dashlane(l)的结果最初似乎并不遵循这种模式,但实际上它们确实遵循这种模式。 Bitwarden(sd)具有相等数量的符号和数字(见下表),使它们以相同的频率被选择。相反,Dashlane(l)具有非随机分布,因为它使用不同数量的大写和小写字母。

RoboForm(l)是唯一不能由此功能至少部分解释的非随机结果,它具有相等数量的大写和小写字符。查看RoboForm的所有字符频率,发现选择的大写字母(“ Z”除外)比小写字母更频繁。此外,字符“ Z”,“ z”,“ 9”始终是最不常用的字符。虽然尚不清楚是什么原因导致了此问题,但假设这可能与使用模块化算术(例如rand()%(maxxmin)+ min)选择字符有关,这可能会对较低值的结果产生轻微的偏差。

随机但较弱的密码:在对zxcbvn结果的分析中,发现偶尔所有密码管理器都会生成异常弱的密码,示例如下表所示。虽然这是真正随机生成器的预期行为,但仍然导致密码不佳。

即使随机生成的长度为8个字符的密码具有抵抗脱机攻击的潜力(例如log10(968/2)= 15.56),密码管理器仍会向用户提供此长度的密码,这些密码容易受到在线和离线攻击。在长度为12时,最弱的密码不再容易受到在线攻击,但仍然容易受到离线攻击。最终,最短的20位密码能够承受离线攻击。尽管这些弱密码的发生相对罕见(少于200个中的1个),但还是最好选择足够长的密码,以使随机的弱密码很可能能够抵抗在线和离线攻击。根据对这些结果的分析,长度为10可以抵抗在线攻击,长度18可以抵抗离线攻击。

 

0x05 Password Storage

密码存储是密码管理器生命周期的第二阶段。为了评估密码存储的安全性,手动检查了每个密码管理器创建的本地密码数据库,以查看哪些信息已加密和未加密,以及检查主密码的更改如何影响数据加密。结合了密码管理器维护人员的声明,客户端可用的选项以及密文格式,确定了如何进行加密。由于无法使用云数据库进行直接评估,因此专注于在本地系统上存储密码库。下表提供了此信息的概述。

1)密码库加密

基于应用程序和基于扩展的密码管理器均使用AES-256加密其数据库。这些系统都使用密钥派生功能(KDF)将主密码(MP)转换为可用于加密的加密密钥。 KeePassX和KeePassXC使用100,000轮的AES-KDF。除Dashlane之外,所有基于扩展的密码管理器都使用PBKDF2,只有RoboForm使用少于100,000轮。 Dashlane是唯一的密码管理器,它使用具有记忆力的KDF,Argon2D,进行了3个回合。虽然默认情况下未使用,但KeePassXC确实支持使用Argon2D代替PBKDF2的选项。

每个密码管理器对主密码的组成都有不同的要求。KeePass和KeePassX都允许对主密码进行任何组合,包括根本不使用主密码。基于扩展的密码管理器都需要主密码,但组成要求有所不同.LastPass,RoboForm和Bitwarden要求主密码至少应包含八个字符,但没有其他限制。 1PassWordX将最小长度增加到10,但是与其他三个相同。

OnlyDashlane具有构成要求,要求最小长度为8个字符,并且每个字符类(小写,大写,数字,符号)中的一个字符。

在基于浏览器的密码管理器中,只有Firefox处理其密码库本身的加密。它使用3DES加密密码数据,使用一轮SHA-1来导出加密密钥。它不对主密码强加任何策略。与处理自己的加密的其他密码管理器相比,Firefox是目前最弱的。

其余基于浏览器的系统依靠操作系统来帮助它们加密密码库。 Edge,Internet Explorer和Safari都依赖于操作系统密钥环来存储凭据。对于Edge和Internet Explorer,这是Windows保险柜;对于Safari,它使用macOS钥匙串。

Chrome和Opera还依赖于操作系统来加密密码,但是它们的操作方式因操作系统而异。在Windows上,CryptProtectData函数用于让Windows使用与当前用户帐户绑定的密钥来加密密码。在Linux上,这些系统首先尝试将密码写入GNOME密钥环或KWallet 4,如果这些钥匙串都不可用,则退回到以纯文本格式存储密码。在macOS上,虽然网站密码本身存储在本地而不是存储在钥匙串上,但是密码使用macOS钥匙串派生的密钥加密。

除Firefox外,基于浏览器的密码管理器均依靠操作系统来加密密码,因此不允许用户建立主密码。因此,无法单独锁定密码库和锁定帐户。尽管不在本文讨论范围之内,但还需要进行更多研究,以研究OS提供的加密功能和密钥链的安全性。

2)元数据隐私

与早期发现相比,发现基于应用程序和基于扩展的密码管理器在确保适当保护元数据方面有了很大的改进。

KeePassX和KeePassXC都加密所有元数据。基于扩展的密码管理器会加密大多数元数据,但是所有密码管理器都至少具有一个它们没有的项目。

1Password X以明文形式存储扩展设置,从而使攻击者可以读取或修改设置。这些设置包括与安全性相关的设置,例如是否启用自动锁定,默认密码生成设置以及是否显示通知。 Dashlane加密网站URL时,不会加密与这些URL关联的网站图标,从而使攻击者可以推断用户拥有帐户的网站。所有基于扩展的密码管理器都会泄漏用于登录密码管理器的电子邮件地址。

依靠操作系统提供(Edge,Internet Explorer,Safari以及Linux上的Chrome和Opera)的基于浏览器的管理器使用这些工具来保护所有相关的元数据。对于其他基于浏览器的密码管理器(Windows和macOS上的Chrome和Opera,以及所有操作系统上的Firefox),存在大量未加密的元数据。所有这三个密码管理器均以明文形式存储URL,只有Firefox会加密用户名。他们还提供有关创建帐户的时间,上次使用时间以及密码填充次数的信息。

 

0x06 Password Autofill

在评估过的密码管理器中,只有KeePassX不支持浏览器中的自动填充功能,而Bitwarden警告说其自动填充功能是试验性的。为了评估这些工具,开发了攻击网站。下表突出显示了本研究的一些发现。

1)用户互动要求

如果攻击者可以通过网络注入或XSS攻击来破坏网页,则他们可以插入恶意JavaScript,该JavaScript将在输入用户密码时窃取用户密码。如果密码管理器在没有首先提示用户的情况下自动填充密码,那么只需访问受感染的网站,用户的密码就会被秘密盗用。因此,理想情况下,应该在自动填充发生之前需要用户交互。在测试的密码管理器中,只有1Password X和Safari在填写凭据之前始终需要用户交互。其余的密码管理器根据提供网站的协议(即HTTPS或HTTP)以及HTTPS证书是否有效而表现出不同的行为。

对于使用有效证书通过HTTPS服务的网站,KeePassXC,Bitwarden和RoboForm默认要求用户交互,但也允许禁用用户交互。尽管可以选择要求用户交互,但Dashlane,Lastpass和Firefox默认自动填充密码而无需用户交互。 Chrome,Edge,Internet Explorer和Opera始终自动填充用户凭据。尽管可以选择要求用户交互(Dashlane,LastPass,Firefox)而不是缺少该选项(Chrome,Edge,Internet Explorer,Opera),但实际上大多数用户(不太可能更改其用户)的结果是相同的默认选项)。

虽然在使用HTTPS的网站上仍然可以进行网络注入攻击(即TLS中间人攻击),但它们更容易实现,并且如果HTTPS证书无效,则更有可能。 HTTPS证书错误的原因包括良性(例如一天过期)到恶意(例如无效签名,已撤销)。在这两种情况下,密码管理器都应该完全拒绝填写密码,或者至少要求用户交互后才自动填写密码。如果证书无效,KeePassXC,Bitwarden,RoboForm,Dashlane,Lastpass和Firefox均会像使用有效证书一样起作用。 Edge和Internet Explorer都会更改其行为,并且始终需要用户交互才能获取错误的证书。 Chrome和Opera还会更改其行为,从而完全禁用自动填充密码的功能。

当使用不安全的连接(即HTTP)为网站提供服务时,网络注入攻击也更有可能并且更容易实现。与错误证书一样,密码管理者应拒绝自动填写密码或在填写密码之前要求用户互动。默认情况下,KeePassXC,Bitwarden和RoboForm仍要求用户互动,但允许用户禁用此要求。 Dashlane,LastPass,Edge和Internet Explorer都将其行为更改为始终要求用户交互,然后才能在HTTP网站上自动填充密码。

2)为iframe自动填充

无论是否需要用户交互,在iframe中自动填充密码都是特别危险的。例如,点击劫持可用于诱骗用户提供必要的用户交互以自动填充其密码,从而使攻击者可以窃取iframe中加载的漏洞网站(同源或跨域)的密码。更糟糕的是,如果跨域iframe允许自动填充并且不需要用户交互,则攻击者可以以编程方式收集所有网站的用户凭据,攻击者可以在其中执行网络注入或XSS攻击(通过将受感染的网站加载到iframe中) 。

对于点击劫持和收获攻击,用户必须首先访问一个恶意网站,然后该恶意网站才能发起攻击,但这通常并不是攻击者的主要障碍。在最坏的情况下,如果系统容易受到收割攻击,并且攻击者可以访问用户的WiFi接入点(例如,在酒店或机场),从而使他们可以轻松进行网络注入攻击,那么所有用户的凭据当用户查看受损访问点的网络登录页面时,可能会秘密地被盗。

KeePassXC,1Password X,Dashlane和LastPass在相同来源的iframe中自动填充,使它们容易受到点击劫持攻击。 Bitwarden和RoboForm也可以自动在相同来源的iframe中填充,但是如果需要用户交互,它们在很大程度上不受点击劫持的影响,因为这种交互发生在扩展下拉列表内的网站外部。所有浏览器都将使用相同来源的iframe自动填充。

KeePassXC确实允许跨域iframe自动填充;默认情况下,它确实需要用户交互才能在跨域iframe中自动填充,但可以禁用此要求,从而使KeePassXC容易受到上述收获攻击的攻击。在基于扩展程序的密码管理器中,1Password X,LastPass和RoboForm不会在跨域iframe中自动填充。 Bitwarden和Dashlane会自动填充跨域iframe,但会自动填充最顶部窗口的域(即显示在网址栏中的域)的密码,从而防止攻击者窃取跨域凭据。

Chrome,Edge,Internet Explorer,Opera和Safari都需要用户交互才能将密码自动填充到跨域iframe中,尽管这仍然使它们容易受到点击劫持攻击。 Firefox默认情况下,在将密码自动填充到跨域iframe之前不需要用户交互,因此默认情况下,它容易受到域捕获攻击的攻击。

3)不同于已保存表格的填写表单

密码管理器会检测用户何时在登录表单中手动输入密码,然后将其保存以供以后使用。当密码管理器稍后填写此密码时,它可以检查要填写的表单是否与保存密码时使用的表单相似(例如,相同的路径或协议)。这些类型的检查有助于确保用户以不妥协的形式输入密码,其安全性等同于他们首次保存密码时所使用的形式。不过,在许多情况下,更改表单仍然有意义-例如,密码已保存在注册表单中(即,不是登录表单)。

因此,如果密码管理器不允许填写表单或在填写表单与用于保存密码的表单之间存在差异时向用户显示通知,则给密码管理器加了一个全点。如果密码管理器在出现差异时需要用户交互,则给出半点,但前提是无法禁用此用户交互(在Bitwarden和RoboForm中可能如此)。请注意,1Password X和Safari始终需要用户交互,因此始终收到至少半个点。在下面讨论的结果中,仅强调由于登录表单中的差异而导致密码管理器的行为不同。

密码管理器不会对提供表单的URL中的差异做出反应(除了检查域是否匹配之外)。如果密码保存在通过HTTPS提供的表单中,Chrome和Opera将拒绝将其填写在具有错误HTTPS证书的表单中,并且Edge和IE要求用户进行交互。如果改为通过HTTP提供表单,则1Password X和Dashlane将警告用户,Chrome,Edge,Firefox,IE和Opera将拒绝填写密码。同样,LastPass将强制用户交互。

如果首次加载页面时,表单的action属性(密码将提交到的URL)存在差异,则KeePassXC,LastPass和Firefox将显示警告,而Firefox也拒绝填写密码。如果在页面加载后(即动态地)更改了动作属性,则KeePassXC和Firefox将显示警告,尽管与之前不同,Firefox会继续输入密码。密码管理器不会对方法属性中的类似差异做出反应。如果表单中的输入字段已被重命名或删除,LastPass将需要用户交互。

4)非标准登录字段

调查了密码管理器是否将用type =“ text”(而不是type =“ password”)填充表单字段,发现在这种情况下只有DashLane会自动填充密码。还检查了这些工具是否会自动填充最小表单(即非登录表单),该表单仅包含两个输入字段:文本字段和密码字段;在这种情况下,自动填充将减少攻击者收集凭据所需的工作。在这种情况下发现Bitwarden,Chrome,Edge,Firefox,IE和Opera都将自动填写这些非登录表单,而其余的浏览器仅在用户明确要求时才填写。

5)潜在缓解

建议使用一种更安全的自动填充形式来解决XSS漏洞,没有将密码填充到容易受到XSS攻击的网页上,而是将随机数作为密码填充到了网站中。当随机数即将通过网络传输到网站时,密码管理器将用真实密码替换随机数。这种方法使网页上的JavaScript无法访问用户的密码。此外,密码管理器可以检查密码仅发送到与该密码相关联的网站,并且密码表单没有提交到其他网站。

本研究检查了所有密码管理器以查看它们是否支持此功能,并发现它们均不支持此功能。在调查此功能时,尝试自己实施该功能,并发现浏览器不允许扩展程序修改请求正文,从而阻止了基于扩展程序的行为密码管理器利用这种更安全的操作模式。启用安全密码输入是浏览器可以做的工作,以改善Web上的身份验证,接下来将对此进行更深入的讨论。

查看当前的W3C规范,尚不清楚autocomplete属性是否应排除登录凭据的存储和自动填充。尽管规范确实指出“用户代理”不应填充标有自动完成功能的字段,但尚不清楚这是仅指主要用户代理(即浏览器)还是用户代理扩展(即密码管理器)。 Mozilla的文档还指出,为了支持密码管理器功能,大多数现代浏览器已明确选择忽略登录字段的autocomplete属性。这有助于解释为什么即使在先前的研究中,浏览器中对此属性有一些支持,也没有密码管理器当前遵循此参数。

6) Web Vault安全性和书签

在线密码库的安全性问题可能会放大自动填充问题。这些Web保险库既包括密码库的独立接口,又充当基于扩展的密码管理器的同步后端。例如,跨站请求伪造(CSRF)可用于更改与一组凭据关联的URL,从而允许自动填充所有用户凭据并从单个恶意域中窃取所有凭据。或者,可以使用Web Vault上的XSS漏洞窃取其所有密码。

本文评估了五个基于扩展的密码管理器及其Web Vault后端,以查看它们是否已正确解决了潜在的CSRF和XSS攻击。发现1Password X,Bitwarden,DashLane和LastPass使用CSRFtokens来防止CSRF攻击。 RoboForm似乎没有使用CSRF令牌,并且能够针对更改了会话超时参数的Web Vault发起CSRF攻击。无法找到其他CSRF攻击,因为Web Vault似乎使用加密身份验证而不是Cookie来验证其他请求。

为了评估Web Vault对XSS攻击的敏感性,手动检查了每个Web Vault的内容安全策略(CSP)标头。评估结果未发现1Password X或Dashlane的CSP政策存在问题。 Bitwarden的政策有两个小问题:script-src允许“self”,而object-src允许“self”和“ blob:”。 LastPass的策略允许在script-src中使用“ unsafe-inline”,从而为XSS攻击留出了很大的空间。 RoboForm的网站没有任何CSP策略。本研究确实尝试为LastPass和RoboForm制作XSS漏洞,但是由于两个站点都进行了广泛的输入清理,因此这些努力没有成功。无论如何,两个Web保管库都将从实施更严格的(或任何)CSP策略中受益。

最后,检查了基于扩展的密码管理器是否仍然具有易受攻击的基于书签的部署选项(用于支持移动设备)。发现除了LastPass之外,基于扩展的密码管理器不再支持基于书签的部署。取而代之的是,密码管理器依靠本机移动应用程序来处理移动设备上的密码管理。 LastPass的小书签可以在受保护的iframe中正确执行代码,并过滤发送给小书签的危险消息,从而解决了Li等人发现的问题类型。

 

0x07 Discussion

研究表明,与以往研究中这些类型的工具相比,基于应用程序和基于扩展的密码管理器得到了改进。通常,他们在解决特定漏洞方面做得很好:改进了对密码库中存储的元数据的保护,删除了(不安全的)小书签,限制了自动填充iframe的能力(防止了密码收集攻击)以及解决了在线密码库的Web安全问题。另一方面,与早期工作相比,它们在处理没有特定漏洞的区域时如何处理密码几乎没有什么变化:警告用户有关填写表单与保存密码的表单之间的差异或XSS缓解措施的实现。同样,基于浏览器的密码管理器在安全性和功能方面仍然大大落后于基于应用程序和基于扩展的密码管理器。

根据发现,建议用户避免使用Firefox的内置密码管理器。特别是,它的自动填充功能极其不安全,并且容易受到密码收集攻击的攻击。如果攻击者可以对用户(例如,控制WiFi访问点)发起网络注入攻击,那么该攻击者就很难窃取用户Firefox密码库中存储的所有凭据。希望这些问题将在Firefox过渡到Firefox Lockbox密码管理器时得到解决。 KeePassXC浏览器扩展程序的用户还应确保他们在自动填充之前不禁用用户交互要求,因为这样做还会使客户端容易受到相同的密码收集攻击。

还建议用户避免使用基于浏览器的密码管理器,而应使用基于应用程序和扩展的密码管理器,因为后者通常具有更多功能,更安全地存储密码,并拒绝在跨域iframe中填写密码。 Safari的密码管理器是其中一个例外,它虽然缺乏良好的密码生成器,但却可以很好地存储密码并避免自动填充错误。

使用基于应用程序和扩展的密码管理器,仍然需要用户确保对其进行正确配置。在自动将密码填充到网站中之前,Dashlane和LastPass都不需要用户交互,并且Bitwarden和Roboform允许禁用此交互。如果禁用了用户交互,则访问受感染网站(例如,攻击者利用了XSS漏洞)的用户可能会在该用户的密码被盗的情况下不知道发生了这种情况。虽然这不像密码收集攻击那样糟糕(现在已由基于扩展的密码管理器阻止),但它仍然是用户无需了解或担心的漏洞。在研究的基于扩展的密码管理器中,只有1Password X拒绝自动填充密码。

1)建议

过滤弱密码:研究表明,密码管理器将随机生成可被在线或离线猜测攻击轻易破解的密码。这是密码生成的自然扩展,它实际上是随机的,即可以生成任何密码,即使它是带有通用替换的自然语言单词(例如,“ d @ rKn3s5”)或表现出重复的字符模式(例如,“’ +’+’+ _ +”)。尽管对于足够长的密码(对于在线抵抗而言,为10个字符,对于离线抵抗而言,为18个字符),这是极不可能的,但仍然可以实现。为解决此问题,建议密码生成器添加一个简单的过滤器,以检查生成的密码是否易于猜测(使用zxcvbn轻松检查),如果是,则生成替换密码。

更好的主密码策略:密码管理器要求用户选择和管理主密码,希望如此,因为他们只需要一个密码,用户便可以选择足够强的秘密。如果用户未能选择好的主密码,特别是如果所选的主密码被在线攻击,那么密码管理器将成为该用户帐户的弱点。不幸的是,信任用户始终选择强主密码是有问题的:(1)用户不一定了解强密码的构成;(2)他们选择的密码可能具有独特的转换,但认为是通用的;(3)用户仍然可以选择简单的密码,因为它更方便。

由于这些原因,建议密码管理器对主密码的选择采取严格的要求,以防止用户将其密码管理器变成弱点。此外,密码管理者都应过渡到使用存储硬KDF来将主密码转换为加密密钥。

安全的自动填充:如果网站受到XSS攻击,则无需用户交互即可自动填充凭据,这些凭据将处于危险之中。因此,建议密码管理器默认在自动填充密码之前要求用户交互。在可能的情况下,还建议您删除禁用用户交互的选项,因为用户不太可能了解将其关闭的含义。自动填充到相同或交叉来源的iframe中也很危险,因为它允许点击劫持攻击来规避用户交互要求。因此,建议您禁用iframe自动填充功能,否则,如果考虑将用户交互活动从网页移出浏览器(如Bitwarden和RoboForm所做的那样)不可行,则使点击劫持攻击变得更加困难。

2)未来工作

浏览器支持的密码管理器:当前,身份验证是浏览器中的第二级。未来的研究应检查浏览器如何更好地支持基于密码的身份验证,例如,使基于密码的身份验证接口成为浏览器实现的一流HTML元素,以确保正确处理密码。这可能包括为基于密码的身份验证提供通用的可识别界面,允许使用替代协议(例如,强密码协议),并防止恶意网站创建类似网络钓鱼的界面。

研究还应探索浏览器如何为密码管理器扩展提供附加功能,包括:(1)允许密码管理器生成现时随机数,以自动填充代替浏览器在以下情况下将其替换为密码的密码:目标域与密码管理器中与密码关联的域匹配; (2)为密码管理者提供对系统密钥环(例如macOS密钥环,Windows Vault)的访问权限,从而为他们提供了一种更安全和标准化的机制来存储帐户凭据; (3)处理自动填充的用户交互组件,并确保其具有抗点击性。 (4)添加描述网站密码策略的HTML属性,允许密码管理者生成将被网站接受的密码。

研究衍生的字符集:密码管理器使用不同的字符集生成密码,它们允许使用的符号以及将其删除为不可用的字符差异很大(例如,难以记住,难以区分)。提倡以数据为动力,努力建立标准化的字符集。

应进行用户研究,以识别用户难以阅读和输入的字符,并注意其他输入方式(例如,使用遥控器或可访问的键盘输入密码)。对现有密码策略的度量也可以用于识别网站密码策略通常拒绝哪些字符。可能是没有一个理想的字符集,而是针对不同类型的密码(例如,具有限制性策略的密码,以非键盘方式输入的密码)使用了不同的字符集。在这种情况下,可以使用统计模型来识别各种形式的密码的理想长度。

HTML支持的密码生成:建议添加HTML属性,以帮助密码管理员识别生成密码时要使用的策略,认为这种方法应引起更多关注。尤其值得一提的是,查看开发人员研究的可行性研究,以将该功能添加到现有网站中,并进行用户研究,以确保该功能易于理解并对用户有所帮助。值得一提的是,是否可以通过语义评估检查密码的代码来自动推断和添加此类注释。

移动端密码管理器:本文工作检查了桌面环境中密码管理器的安全性,考虑到移动设备的普遍性,有必要对移动密码管理器的安全性进行类似的分析。

 

0x08 Conclusion

媒体目前正在建议使用密码管理器,但用户在选择密码管理器时需要谨慎,并且还必须花费时间来确保他们了解如何正确配置它。正如经验所表明的那样,将这些责任推给用户很少会有预期的好结果。因此研究人员要继续评估密码管理器的发展进度,并且要努力继续提高密码管理器的安全性和可用性。

本文翻译自usenix.org 原文链接。如若转载请注明出处。
分享到:微信
+123赞
收藏
CDra90n
分享到:微信

发表评论

内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66