财务数据的适当加密[关闭]答案

【问题标题】：Appropriate encryption for financial data [closed]财务数据的适当加密[关闭]
【发布时间】：2017-12-08 17:58:13
【问题描述】：

我目前正在构建一个 Web 应用程序 (PHP/MySQL)，用于保存来自人员的数据。这些数据中的大部分不值得通过加密保护，但其中一些是收入等财务信息。它不是一个支付应用程序，不存储可以像信用卡信息一样直接转化为金钱的信息，但仍然是您不希望在可能的泄漏中拥有的东西。这个平台必须卖给想要“安全”的客户，但这可能意味着任何事情，因为客户自己并不知道他们真正想要什么，因为他们是商人而不是密码学家（我也不是）。

这是一个管理平台，因此保存财务数据的人不是该平台的用户。该平台的用户只是一个附加权限的登录名。服务器本身永远不必访问数据。每个操作都由登录的用户（也可以是管理员）完成。多个用户需要访问相同的数据，因为他们有足够的权限。

我现在的问题是如何保护财务数据免受这些威胁：

有人发现 SQL 注入并远程转储所有表
有人盗用服务器硬盘（数据库+代码）

我肯定不会去的地方：大规模嗅探攻击或受损服务器（例如在 SSL 无关紧要的情况下嗅探服务器本身的所有流量）或社会工程/网络钓鱼。

我还想快速总结一下与当前系统相比，我还需要存储多少信息（密钥、数据等），当前系统只有一个简单的收入字段等，还有一个标准登录系统带有用户名和哈希密码。

编辑：几乎完全按照 cmets/answers 的建议重新提出问题

【问题讨论】：

我认为您会使用用户密码（但不是密码本身或您保存在数据库中的密码哈希）以可重现的方式生成的密钥做某事，那么您d 要求每次用户需要访问敏感数据时输入密码。这样您就不会将加密密钥保存在代码中。在这种情况下，它的对称或不对称并不重要。
@apokryfos 我确实编辑了我的问题，并且可能澄清了一些事情。我想你的评论已经很接近了，所以我也想得到你的答案，这样我就可以投票了:)
“我目前正在构建一个 Web 应用程序......这个平台必须卖给客户......” - 您的公司可能应该寻求安全服务建筑师。要么聘请一位，要么咨询一位。您要避免的一件事是将其展示给公司，而该公司的一位安全架构师会审查并拒绝它。（我曾经是审查供应商产品的安全架构师之一。它们被称为“安全架构评估”）。

标签： php mysql security encryption

【解决方案1】：

这里有两种方法：

1) 使用对称加密，因为您已经与客户端安排了一个秘密，即他们的密码。

每当用户需要访问其敏感信息时，他们都需要提供密码。如果您需要，那么您可以使用该密码作为生成加密密钥的基础。

您可以使用 PHP 中的openssl 函数对敏感数据进行加密，并在客户端需要时对其进行解密。这将允许您选择 OpenSSL 支持的适当难以破解的算法。这样做的缺点是您需要明确的用户权限和密码才能访问该数据，如果您只是代表该用户存储它，这很好，但如果您需要将其传递给其他人，则不好。

这样您就不需要在数据库中存储其他信息。万一有人偷了你的硬盘，他们所拥有的只是加密的敏感数据和散列密码。缺点是它是单点故障，如果他们破解加密，他们也会得到密码，反之亦然，但是破解加密的难度不如反转哈希高。它还依赖于强密码，我们知道用户通常不倾向于使用，但这不是一个新问题，也是我们今天不太可能解决的问题。

2) 要求用户生成私钥-公钥对并将公钥发送给您。然后，您可以存储此公钥并使用它加密数据。如果您有一个与您的服务器通信的应用程序/软件，这通常会很好地工作，它可以代表用户执行此操作，但更难在 Web 应用程序中实现。也许有 JavaScript 库可以做到这一点，但由于这不是通常做的事情，你需要 100% 确定你使用的库是安全的。然而，这也要求用户将密钥存储在某处，并能够在他们想要访问该数据时使用它（同样，JavaScript 可以为用户执行此操作，但由于安全问题，保存和加载密钥需要用户交互)。

简而言之：

对称加密只有在加密密钥没有存储在服务器上但用户可以在需要时提供的情况下才是安全的。
在面向普通用户的 Web 应用程序中，非对称加密更加安全但不切实际。

所以我建议使用用户密码作为密钥进行对称加密。

【讨论】：

如果我希望多个用户访问相同的数据，是否需要存储数据的多个加密副本？或者至少是数据加密密钥的多个加密副本（使用用户密码）？并且可以在会话期间将加密数据存储在内存中吗？
@SkryptX 对于第一部分，如果您希望其他人查看敏感数据，那么整个方法就会失败。在这种情况下，您可以将非对称加密与安全存储在某处（在不同服务器上）的特定私钥一起使用，并能够使用授权和经过身份验证的用户的凭据来检索该密钥。对于第二部分，在某些时候将敏感数据保存在内存中是不可避免的。您所能做的就是在不再需要它时正确处理它，并注意缓冲区溢出/下溢攻击。
拥有 20-30 个使用不同密码加密的解密密钥副本有那么糟糕吗？如果密码是安全的，那只会将强度降低 20-30 倍，这仍然需要大量的计算，还是我太天真了？ :S
@SkryptX 在您显着改变问题后，我添加了另一个答案。在保持安全性的同时允许用户查看相同的信息是可能的。虽然这个答案的作者是正确的，可以在这里使用非对称加密，但这绝对不是一个优雅的解决方案。正如我在第二个答案中解释的那样，仅使用对称加密就可以实现更清洁的系统。
另外，@apokryfos，您能否引用您的“破解加密的难度不如反转哈希”的参考？

【解决方案2】：

从您的问题中，可以看出以下关键点。

服务器本身永远不必访问数据。
如果有足够的权限，多个用户需要访问相同的数据。
即使在以下情况下也能保持安全性：
- 有人发现 SQL 注入并远程转储所有表。
- 有人窃取了服务器的硬盘驱动器（数据库 + 代码）。

这是可能实现的，但并非易事。使这成为可能的原因是服务器不需要访问数据。这允许我们使用用户密码来派生密钥。

您的权限结构中的每个级别都有一个关联的密钥。此密钥将用于加密可以使用这些权限查看的数据。创建第一个管理帐户时，为您的权限结构中的每个级别生成一个密钥，并将管理密码用作 KDF 的输入并派生一个密钥。使用此密码派生密钥加密每个权限密钥并将生成的密文与管理帐户一起存储。

当新用户由管理帐户创建并分配等级时，提取新用户将有权访问的最高级别权限密钥以及较低权限的任何密钥，使用管理密码对其进行解密（这将是创建用户所必需的），然后使用新用户密码再次对其进行加密，并与新用户一起存储在数据库中。

此系统允许您将所需的加密密钥传递给每个用户，并使得访问用户权限级别以上的数据在加密上是不可能的。

此时，您可以直接让用户访问数据，只需获取他们的密码，解密相关的权限密钥，然后使用该密钥解密数据。用户更改密码也很简单，因为这只是意味着您必须使用旧密码解密权限密钥，然后使用新密码重新加密。

在技术层面，我会推荐以下内容：

使用 AES。 AES-256 往往是最常见的，但 AES-128 在总体方案中同样安全。使用经过身份验证的块模式 (GCM) 在这里并不重要，但仍建议使用。如果没有，请使用带有 HMAC 的 CBC 或 CTR 等模式。
切勿将密码直接用作密钥。使用 PBKDF2 从密码生成密钥。在这里使用 AES-256 非常合适，因为您可以使用 SHA-256 作为 PBKDF2 的原语并获得与内部散列函数相同长度的输出。
每次使用 CSPRNG 加密时都会生成一个新的随机 IV。在密文前加上 IV。不要像密钥一样从 PBKDF2 派生 IV。

【讨论】：

感谢您的详细回答。所以会有#userswithpermission 版本的权限密钥刚刚用不同的密码加密（它的KDFd 版本）？而且我确实需要保存 IV 才能再次解密密文，对吗？就像加盐哈希一样？
是的，这是正确的。是的，您需要存储 IV。每次加密时将 IV 添加到密文中，然后在解密时将其删除并使用它。它与盐的唯一相似之处是它是完成操作所需的信息。他们没有其他共同点:)

【解决方案3】：

非对称加密和混合加密在这里毫无意义，除非用户自己生成并保留私钥的所有权。我从你的其他问题推断出情况并非如此。

假设您希望能够在没有用户交互的情况下查看此加密信息（例如，您不只是为用户存储此信息，并且该信息与您的业务运营相关），那么您的存储选项有限。

如果您的确切威胁模型是在发生数据库泄漏时保护此数据仅此而已，如果实施得当，对称加密是完美的。

这意味着对称密钥必须存储在向数据库发出请求并将数据提供给您的其他（可能是前端）系统的服务器上。如果这些服务器中的任何一个受到威胁，那么加密的数据就会泄露。

总之，使用对称加密，但要明白，它只会通过 SQL 注入或类似攻击等方式直接保护您免受数据库泄漏。受感染的服务器是受感染的服务器，通常意味着在有足够时间的情况下可以完全访问数据。

编辑：如果您打算要求用户交互以查看受保护的数据，那么 apokryfos 上面的评论准确地详细说明了如何保护信息。从用户密码生成一个对称密钥，并使用它来加密一个额外的对称密钥。使用此辅助对称密钥来实际加密数据。使用两个密钥可以更轻松地更改用户密码。

【讨论】：

非对称加密背后的想法是，多个人可以访问相同的数据，同时所有数据都被加密。因此，当敏感数据被访问时，始终是具有相应权限的用户。因此，如果有人复制所有内容（db+code），他们仍然需要找到密码。但是您对受感染服务器的评论显然是正确的，这使得这种说法毫无用处。
@SkryptX 嗯，我认为您可能误解了非对称加密的某些方面？编辑您的问题以澄清您是否还需要在没有用户交互的情况下访问数据可能是一个好主意。
我几乎完全编辑了我的问题。也许这更好地解释了我的问题。我也确实误解了非对称加密能做什么和不能做什么。