加密秘密信息数据库：全部还是部分？答案

【问题标题】：Encrypting database of secret information: Entirely or in parts?加密秘密信息数据库：全部还是部分？
【发布时间】：2011-12-17 22:12:38
【问题描述】：

假设您有一个充满秘密信息的数据库，例如用户名 + 密码列表。

如果您想使用 AES-128 等算法加密此数据库，您将如何加密数据？

仅加密机密信息字段，例如密码。保持用户名不变。输出可能是：“mike@example.org/AES_ENCRYPTED_PASSWORD;linda@example.org/AES_ENCRYPTED_PASSWORD”
加密整个数据库，输出为：“AES_ENCRYPTED_DATA”

我在想的问题：可能数据是以XML格式保存的。因此，可能的攻击者可以使用蛮力尝试随机密码，直到他在加密数据中找到 XML 元素。所以它比第一种方法更容易破解。对吧？

或者将我的数据暂时保存为 XML 格式，然后使用 AES 加密整个 XML 文件是否安全？

【问题讨论】：

我不会将 XML 文件称为数据库。但您首先应该考虑您希望如何存储和使用此数据库，以及为什么（对谁）希望它首先受到保护。
您想要加密还是散列？它们是两种截然不同的东西。到目前为止的答案是假设您真的想要散列 - 如果目的是存储用户的密码以便您可以验证他们的登录尝试，这是有道理的。但是，如果您正在创建一个系统来存储您自己的密码以便您可以检索它们（例如PasswordSafe），那么散列对您没有好处；你需要使用加密。你想做什么？（无论如何，使用一些现有的软件可能比使用自己的软件更好。）
是的，我知道区别。我真的想要加密。你是对的，我正在考虑像 PasswordSafe 这样的东西。所以我想创建一个密码存储系统。但是为什么我应该更好地使用一些现有的软件呢？我认为自己创建一个是一个很好的挑战，我可以学到很多关于编程安全性的知识，对吧？

【解决方案1】：

据我了解 OP，问题更多的是“已知明文”以及要加密的消息的大小和冗余。

所以：

是的，在大多数情况下，如果部分明文是已知的，例如 XML 标记，那么破解加密“更容易”。

是的，如果有更多加密数据可用，可能会更容易破解加密。

但是：所有常见的现成加密算法，尚未被视为“损坏”，对这两种类型的攻击都具有相当的免疫力。

理论上，如果只加密几乎随机内容（如密码）的短消息，实际上应该更安全。但是，如果独立加密许多此类消息，则必须考虑初始化向量（类似于“salt”）等，以避免产生实际上打算隐藏的模式。

结论：

采用具有良好密钥/密码/...的“良好”算法 - 如果可行的话 - 将您的“数据库”加密为一条大的明文消息。

或者仅 [...] 使用 AES 加密整个 [数据库] 文件是否安全？

是的，这就是我原则上会推荐的。但要非常小心“临时”存储数据的方式和位置；例如，“临时”目录中的文件可能不像人们想相信的那样“临时”。

【讨论】：

非常感谢，这正是我所要求的。你已经正确理解了我的问题。所以你同意我的观点，至少在理论上，只加密密码并保持其余部分不变应该更安全。但在实践中，安全性几乎相同，应该真正将整个数据文件加密为一条大明文消息。正确的？所以攻击者不会因为知道他会在解密的文本中找到 XML 标记而完成一项简单的任务？
实际上，我的意思更像是相反：将整个数据库加密为一个整体时，您实际上不会失去安全性。但是，在处理超过 10 个密码时（假设所有密码都使用相同的密钥），要对仅密码进行加密不容易。此外，常见的加密工具会在加密之前对您的数据进行无损压缩，从而消除 XML 标签等数据中的大部分冗余。
哦，好的 :) 谢谢你的澄清！所以结果可能是可以毫无问题地加密整个数据库或 XML 文件，对吗？在这种情况下，人们不必担心失去安全性。
是的，我就是这么说的 :)

【解决方案2】：

如果您使用相同的密码，无论是一堆用户名/密码还是一组 XML 文件，难度都是一样的。

只加密您必须加密的内容。虽然在密码方面，加密并不是一个好主意，因为密码可以恢复（这会将密码泄露给潜在的攻击者）。

如果用户不记得他们的密码，最好存储一个哈希并有一个生成新密码的机制。

【讨论】：

【解决方案3】：

最好将密码存储为带盐的哈希。

【讨论】：