KWallet密码加密应用程序的安全性？

Question

根据http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/的说法，KWallet密码管理系统非常薄弱，它使用密钥分割、Blowfish 56和无盐。

密钥生成可以描述为-将用户密码分解为16个字符的块，并在每个字符上应用SHA1 2000次。这是没有盐的关键伸展。然后对这些块进行裁剪和级联，以适应56个字节，这是Blowfish密码所允许的最大密钥长度。

它还说，尽管它使用CBC，但它使用CBC的方式变成了欧洲央行。

KWallet使用CBC，或者准确地说，它假装-用于CBC的密钥大小是要加密的字符串的长度，这将CBC变成了密码的不太安全的模式- ECB。

我的问题是，我对根用户使用的密码与我的KWallet使用的密码相同。/etc/ .kwl只能通过根用户读取，但是任何人都可以读取我的文件，因此任何人都可以获取该文件，并尝试强行执行该文件，可能会成功。

那么有什么方法可以提高KWallet的安全性吗？它不仅适用于我手工输入的密码，也适用于依赖KWallet存储密码(如Chromium)的浏览器和应用程序，所以我不能只切换到另一个程序。也许我可以编辑源代码，或者找到兼容的分叉？

我的最后一个问题是:是否有任何方法可以提高KWallet的安全性，以及有多大程度的安全问题是使用它？

Answer 1

你引用的博客文章在形式上是相当不精确的。但是，通过查看KWallet源代码，特别是这个文件 (用于密码哈希)和那个档案 (用于调用加密代码)，我们可以看到以下内容：

通过重复应用SHA-1，将密码扩展为大小为20、40或56个字节(160、320或448位)的对称密钥。即：

• 如果密码的长度为0到16个字符，则键的长度为20字节，并且是SHA-1 (2000次)在密码上的重复应用(密码被散列，然后20字节的输出将被再次散列，并再次用于SHA-1的2000年调用)。
• 如果密码的长度为17至32个字符，则键的长度将为40字节:前面的16个字符将按上述方式处理，其余的字符将得到类似的处理，从而产生20个字节。
• 如果密码的长度为33至48个字符，则键的长度为56字节:前面的16个字符将按上述方式处理，第二个块包含16个字节的字符，然后是第三个块；然后第一个块的输出被截断为16个字节，总共为56个字节。
• 如果密码有49个或更长的字符，那么2000 SHA-1调用将发生四次。对于第四个块，将使用完整的其余密码。然后，将四个20字节的输出分别截断为14个字节，并将它们连接起来，从而产生56个字节的输出.

作为一个密码散列功能，它是相当差的。它很笨重，不规律。当多个KWallet实例必须被破坏时，它不会被咸化，从而允许高效的并行攻击(与往常一样，“并行性”也意味着可以使用预先计算的表，从而抵消了2000 SHA-1调用的减速效应)。此外，它“拆分”了密码，因此如果攻击者找到密码哈希，那么他就可以独立地攻击每个块。这意味着整个程序的安全性在很大程度上取决于Blowfish块密码在用作哈希函数时的性能。这充其量不过是一项研究不足的财产。

加密声称使用CBC，但不使用。在CBC中，您应该对块序列进行加密(使用Blowfish，每个块有8个字节)；在对块进行加密之前，首先使用前一个加密块进行XORed加密。对于第一个块，我们必须调用一个正式的“前一个块”，即初始化向量。CBC需要随机的IV。

在KWallet代码中，我们看到代码确实准备了一个大小正确的随机IV .那就完全不能做CBC了。对加密的调用是：

int rc = bf.encrypt(wholeFile.data(), wholeFile.size());

(backendpersisthandler.cpp第291行)

查看这个encrypt()方法的实现，在cbc.cc中，我们看到它将创建一个与整个文件大小相同的临时缓冲区；然后用零填充它；然后用要加密的数据来XOR所有这些零(这不会改变数据.)；然后独立地加密每个块。这确实是欧洲央行的模式，而不是CBC。很明显，这是一个编程错误；但是，我们要吸取的教训是，由于KWallet看起来工作正常，所以没有检测到错误:安全性不能通过功能进行测试。

(这意味着计算出来的随机IV在这里什么也不做；它是由自己加密的，但不会影响整个文件中的任何其他字节。)

众所周知，欧洲央行模式在以下方面很弱:它泄露关于哪些块彼此相等的信息。对于未压缩的图片，这是致命的，正如通常的企鹅图像所显示的那样。对于一个KWallet来说，这是一个令人担忧的问题:内部结构有一些冗余，这可能是可利用的，尽管它需要一些努力来确定问题的范围。

请注意，由于密码未被盐碱化，使用相同密码保护的两个连续版本的KWallet将使用相同的对称密钥，因此欧洲央行泄露的阻塞等式适用于所有后续版本的KWallet。

有一个自制的MAC。文件的最后20个字节(不包括一些填充)包含对其余部分计算的SHA-1值。一般来说，这并不是一个好的MAC。如果加密使用RC4或CTR模式下的分组密码，那么这将是一个非常糟糕的MAC。使用欧洲央行模式的分组密码(如这里所使用的)，它没有那么糟糕，但仍然很糟糕。

整个代码都散发着自制密码的臭味，这些密码都是由不掌握这些概念的人拼凑而成的。这很糟糕。此外，我发现代码在许多方面都很糟糕(例如，当密码块被散列时，重复调用SHA-1的循环就会被无情地复制；这是一种射击攻击)。为了“改进”KWallet，我建议删除整个代码并从头开始。

代码似乎包含了一些可选的支持，用于不执行密码哈希和加密本身(正如我们看到的，它做得非常糟糕)，而是使用GnuPG。这是个好主意。GnuPG实现了OpenPGP格式，尽管它有许多缺点，但至少在密码学方面(如果使用得当)，GnuPG也是一个相当好的实现。若要改进KWallet的存储，请查看是否可以说服计算机使用此GnuPG支持代码和格式。

Answer 2

是我写了最初的博客文章。我还编写了一个Python脚本来读取KWallet文件，这应该比原始的KWallet代码更容易理解。

不过，汤姆对他的分析很在行。我试着为普通用户写文章，但没有深入了解技术细节。KWallet代码处于可怕的状态，除了所描述的安全问题之外，该代码的文档非常贫乏。KDE 5将带来一个全新的密码存储，这还需要一段时间。

KWallet with GnuPG正在开发中，但尚未发布。它会随KDE 4.12而来。

Answer 3

• 首先，您应该做的是不要使用与root用户相同的密码。根是神圣的！
• 通过创建一个TrueCrypt卷并将其放到其中，您可以更好地保护密码数据库。
• 你可以编辑源代码，但前提是你真的知道你在做什么。如果你不知道在源中到底该做什么，你可能会让情况变得更糟。
• 最后，您应该看看KeePass --它是开源的，跨平台的，以及一个很好的密码生成器/管理器。