密码管理器（PM）安全机制和问题研究
1 研究背景
随着身份认证技术的发展，除了传统的用户名/密码认证之外，动态口令认证、智能卡认证、生物特征认证也逐渐在该领域中占领一席之地，但仍然存在一些安全性问题和硬件上的限制。因此用户名/密码认证时至今日仍然是最主流的身份认证形式，且密码通常需要满足如下两点要求：其一，允许用户合法访问帐户、服务、设备、数据和网络；其二，防止未经授权的访问。在可以预见的未来，由于用户名/密码认证在安全性、可用性和可部署性方面的优势，该形式仍将在用户认证中占据主要地位。
在基于用户名/密码的身份认证中，密码管理器已经成为了权衡安全性和可用性的最佳方式之一。跨设备的同步。总的来说，密码管理器以最小的可部署性成本提供了巨大的安全性和可用性优势。如今，密码管理器已成为数百万个人和中小企业（SME）的最佳选择之一。然而，密码管理器只有在保证其自身安全的情况下才能实现其目的；否则，密码管理器将成为单点故障，使用户面临更大的安全漏洞，可能泄露更多的隐私信息。
因此，本文主要探讨密码管理器的安全机制和安全问题。
2 密码管理器简介
密码管理器是一种存储和管理用户名和密码等认证信息的工具，用于在登录时向用户提示（有时会自动填写）正确的认证信息，从而将用户从记忆敏感信息的负担中解脱出来。密码管理器的工作方式如下：用户首次访问网站并在在线表单中输入认证信息时，密码管理器会在其后端存储此类认证信息，并维护凭据与域名之间的关联。当用户再次访问同一域名时，密码管理器会识别并验证域，并提示在相应的登录表单中填入认证信息。
随着密码管理器的逐渐发展，其所支持的平台也丰富起来。除了目前主流的Windows，Mac，Linux桌面平台之外，在Android，Windows Phone，Symbian等平台上均有密码管理器应用。
如今的密码管理器大致可以分为两大类。第一类是由浏览器供应商提供的，作为浏览器的插件，在用户访问登入网页时自动记录用户的账户和密码并在用户下次登陆时自动填充。例如，最受欢迎的五种浏览器：Intemet Explorer，Firefox，Google Chrome，Safari和Opera，均有其插件形式的密码管理器。从易用性来看，插件形式的密码管理器能自动记忆和填充账号和密码，省去了用户查找密码的麻烦，并且全程用户不需要复制密码，避免了被记录剪贴板的攻击获取密码。第二类是由第三方供应商提供，作为一个独立的应用程序，例如KeePass、Password Safe、LastPass、1Password等，其中又可细分为基于本地的和基于云的密码管理器。它们在用户的设备上独立运行，用户在需要使用密码时打开应用进行查询。应用程序形式的密码管理器则能记忆更多的密码，不受浏览器使用资源的限制，能调用更多的系统资源，执行更复杂的加密，并且功能更为强大。目前一些知名公司推出的密码管理器也陆续支持了多平台多形式，结合插件和应用程序，甚至提供网页版简化用户查找密码的程序。
3 密码管理器的发展及安全性分析
3.1 密码管理器的发展
从数据存储的发展时间顺序来看，可以将密码管理器分成三类。
最早期的是本地存储的密码管理器，它们选择将密码数据库加密保存在本地设备。通过充分利用本地的计算资源，本地存储的密码管理器可以实现高强度的加密。然而随着GPU的发展，穷举攻击的速度不断提高，高强度的加密也不再安全。一旦攻击者设法通过物理访问直接获取数据库，就可以通过分析其存储机制，来实现如第三章中所介绍的穷举攻击。此外，在密码填写期间，密码管理器仍然需要在内存中对其进行解密。因此，完全控制设备的攻击者还可以通过内存扫描或其他复杂攻击来窃取密码。
然后是单云存储的密码管理器，它们选择将用户密码存储在单个云端，并且只在登录时向设备发送密码。然而，云本身引入了新的攻击，因为它可能遭到单点突破。恶意云运营商可以轻松窃取已保存的密码，此外根据LastPass和KeePass最近的新闻报道，在云数据库中存储的用户加密数据同样容易被窃取并成功实施穷举攻击。
近年来多云存储的密码管理器，它们选择应用秘密共享算法，将用户密码存储在多个云端。与前两类密码管理器相比，显然多云存储的安全性更强。因为基于秘密共享算法，即使攻击者获取其中的部分数据，也无法得到任何有意义的信息。然而现有的多云存储密码管理器仍然存在数据可靠性问题。
3.2 现有多云存储密码管理器的安全性分析
2015年，李定波等人提出了一种多云存储的密码管理器，其中采用了AONT-RS秘密共享算法。
AONT-RS算法与经典的Shamir算法相比，虽然效率大大提高，但是其安全性有所下降，且缺乏一定的鲁棒性。当一个或几个云存储服务器中的数据遭到恶意篡改时，AONT-RS算法仅仅能够识别出还原错误的情况，但无法准确判断哪些数据是虚假的，因而无法还原出正确的原始秘密。
2017年，Licqun Chen等人为了防止密文长度较短时AONT-RS算法可能导致的信息泄露问题，采用了承诺方案将AONT-RS算法扩展为鲁棒的AONT-RS，即RAONT-RS算法。在改进的RAONT-RS算法中，将AONT-RS算法进行信息分散后的秘密信息块通过承诺方案计算出认证信息，再将认证信息与秘密信息一同分散存储。而在秘密信息块组合之前，增加认证的过程，通过认证信息对秘密信息块的真实性和完整性进行认证。最终只挑选认证成功的秘密信息块进行组合，从而确保可以正确地恢复出原始秘密。
2017年，Hannah Li等人提出了一种多云存储的密码管理器Horcrux，作为Firefox的插件而实现。
Horcrux 密码管理器的设计具有三个特点。第一，Horcrux最大限度地减少秘密信息的暴露。第二，为了避免信任集中式存储，登录凭证利用Shamir秘密共享算法存储在多个服务器上。第三，Horcrux还采用杜鹃哈希算法，混淆数据存储的真实位置，以确保攻击者无法确定猜测的主密码是否正确。
然而，Horcrux在数据存储方面还存在较大的不足。Horcrux在数据存储中采用了Shamir的秘密共享算法，将用户的账户和密码信息存储在多个云端。经典的Shamir算法虽然保证了数据的安全性，但是主要存在两大缺点。第一，Shamir秘密共享算法的存储和传输所占用的资源量很大，计算复杂度较高，且Horcrux中需要进行秘密共享的数据量较大，因此在一定程度上影响了密码管理器的可用性。第二，Shamir秘密共享算法存在数据可靠性问题。具体来说，Shamir算法无法检测或预防篡改攻击。一旦所选取的大于等于k个参与者中存在一个参与者所持的数据是被篡改的，就无法正确恢复出原始秘密。而Shamir算法由于缺乏验证环节，也无法在恢复秘密发生错误时给出提示，更无法指出哪些数据是被篡改的。因此Shamir算法完全无法检测或预防篡改攻击，导致密码管理器的鲁棒性较低。
4 安全机制研究
4.1 KeePass的安全机制研究
加密算法与哈希算法
KeePass 1.x中使用AES/Rijndael或Twofish加密算法；而KeePass 2.x使用AES或ChaCha20（256位）加密算法，且存在扩展补丁可支持其他加密算法，如Twofish、Serpent和GOST等。众所周知，AES算法是安全且成熟的加密算法，被广泛使用；而Twofish也曾是AES算法的候选算法之一；Chacha20则是Google采用的新式加密算法，继承自Salsa20算法。
KeePass加密采用CBC模式，每次保存数据库时随机生成初始化向量（IV）。因此，使用相同的主密钥加密多个数据库是安全的。
为了保证数据的真实性和完整性，KeePass1.x中使用SHA-256哈希算法；而KeePass 2.x中使用HMAC-SHA-256哈希算法。哈希算法用于将复合主密钥（由密码，密钥文件，Windows用户帐户密钥和/或插件提供的密钥组成）压缩为256位的密钥K。
KeePass的存储机制
KeePass 1.x中使用KDB数据库格式，内部为二进制格式；而KeePass 2.x中使用KDBX4格式，内部为XML格式，且可选择在加密之前使用gzip算法进行压缩。KeePass1.x中支持的数据库文件导入格式仅包括CSV、CodeWallet（Pro）TXT、Password Safe TXT和KDB；而KeePass2.x中支持的数据库文件导入格式超过了35种。至于数据库文件导出格式，KeePass1.x中支持XML、HTML、CSV、KDB和ITXT格式；KeePass2.x中支持XML、HTML、CSV、KDB、KDBX和XSL-TTansfomed格式。值得注意的是，虽然KeePass1.x和KeePass2.x所支持的导入和导出格式数量有所差别，但是都可以通过补丁来扩展其支持的格式种类。此外，仅有KeePass 2.x支持通过URL打开数据库、数据库共享编辑和同步机制。
4.2 Password Safe的安全机制研究
Password Safe是一款开源的密码管理器，由知名的密码学专家Bruce Schneier所设计。Password Safe主要支持Windows操作系统，也有单独用于USB闪存盘的版本。此外还有很多开发者编写了相关的变体用于支持其他各种平台。Password Safe还支持ubikey 验证器以实现基于Yubikey和主密码的双因素认证，从而增强其安全性。
Password Safe的加密机制
与KeePass 相比，Password Safe的加密机制更加简单。Password Safe中使用Twofish加密算法和256位密钥，使用SHA-256哈希算法。通过阅读Password Safe3.45的源代码，得知其使用的密钥导出函数如下：StretchKey（salt，sizeof（salt），passkey，NumHashlters，usedPtag），该函数中仅仅将 passkey和salt依序拼合进行一次SHA-256然后进行了NumHashlters次SHA-256得到usedPtag。
接下来usedPtag便作为Twofish的密钥，对数据库的内容进行加密。该密钥导出函数来源于Bruce Schneier于1998年发表的论文，与KeePass中所使用的AES-KDF和Argon2相比，安全性略低。
Password Safe的存储机制
与KeePass相比，Password Safe的存储机制也要简单得多。Password Safe中使用PasswordSafev3，简写为psafe3数据库格式。该格式的文件同样可以在逻辑上分为两部分：文件头（hdr）和加密的主体（bdy）。在hdr中包含用于密钥导出的盐和计算次数，以及加密密钥的哈希值（用于验证）。而bdy中则包含各种已加密的数据库条目。
5 相关攻击介绍
5.1 针对本地数据库的攻击
针对密码管理器本地数据库的攻击主要分为被动攻击（信息窃取）和主动攻击（信息篡改）两种。
在2012年，GastiP等人对九种主流密码管理器的存储机制分析后，发现其中大多数密码管理器的存储和验证流程中都存在或多或少的漏洞，例如由于缺乏完整性保护，可以对文件头中一些关键的未加密字段乃至对已加密的文件主体进行篡改。其中KeePass 2.x、PINs和Password Safe能够抵御被动攻击，而主动攻击仅有Password Safe能够抵御。尽管如此，Password Safe仍存在其他安全上的设计缺陷，GastiP指出在主密码更改之后，攻击者使用原来的主密码仍然可以解密或修改最新的数据库。
当然，由于针对数据库攻击的发现时间较早，因此如今各主流密码管理器都已对其存储和验证流程进行了完善以修复其安全漏洞。
5.2 针对进程内存的攻击
针对进程内存的攻击主要是指在密码管理器运行过程中，通过运行其某些功能，试图从进程内存中的某些位置窃取敏感数据。
2016年，GrayJ等人对三种本地密码管理器：KeePass（v2.28），Password Safe（V3.35.1）和RoboForm（v7.9.12）成功实现了进程内存的攻击。例如，当计算机的内存容量低时，KeePass和RoboForm的主密码会被明文存储在硬盘驱动器的pagefile.sys中；KeePass在处理导出请求之前不要求用户重新输入主密钥，且导出的HTML文件中以纯文本形式包含数据库，可以在浏览器中查看，在导出的HTML文件被复制到其他地方之后，本应被永久删除的原文件仍可在回收站中找到；KeePass在处理打印请求之前也不要求用户重新输入主密钥，且打印失败的内容会以纯文本形式保留在Temp文件夹中；Password Safe在不正确的关机过程中会把复制到剪贴板的数据以纯文本形式保存在pagefile.sys中。
由此可见，即使这些密码管理器始终保持数据库的加密和保护，攻击者或恶意软件也可能通过进程内存攻击窃取到用户的敏感信息。
5.3 针对自动填充的攻击
绝大多数的密码管理器都有自动填充功能，即在需要登录的网页上为用户自动填充其账户和密码。自动填充的策略可以分为两大类：一种是不需要任何用户交互的完全自动填充，一旦登录页面加载就填写用户名和密码字段；另一种是在自动填充之前需要一些用户交互的手动自动填充。其中用户交互包括点选或输入用户名字段，按键盘的快捷方式或按浏览器中的按钮等。
2014年有大量关于自动填充攻击的研究工作，研究表明当时的密码管理器自动填充功能中存在一定的漏洞，远程网络攻击者可以通过扫描攻击（例如通过使用HTTP登录页面、XSS注入等技术将JavaScript代码注入到易受攻击的网页）从用户密码管理器中提取多个密码，而无需与用户进行任何交互；也可以通过劫持攻击欺骗用户进行交互从而获取密码。
5.4 针对移动密码管理器的欺骗映射攻击
下面介绍几种典型的移动端密码管理器遭受的攻击。
Dashlane密码管理器已有超过一百万用户安装，它支持a11y，Autofill Framework和Open YOLO3 种机制。其映射的第2层非常容易受到欺骗。只要将应用商店包名称包含3个（或更多）与恶意用户想要定位的域名重叠的字母的恶意应用程序上传到应用商店就足够了，这种情况下，恶意应用程序将自动填充受害者域的认证信息。
1Password密码管理器已被超过一百万用户安装，它支持ally，Autofill Framework和OpenYOLO3种机制。与先前分析的密码管理器不同，1Password专注于登录类别，按类别（例如：信用卡、数据库、驾驶执照、登录、无线路由器等）组织其条目。1Password不提供任何映射，但它通过可搜索列表轻松地建议每个存储的凭证，将选择权交给用户。换句话说，其可以使用任何存储的凭证自动填充任何请求应用程序。因此，利用1Password很简单，不需要进一步定制应用程序。但是，同样由于无映射的方式，恶意用户无法对自动建议的凭据列表进行细粒度控制，因此这种欺骗不如其他恶意行为实用。