.NET DPAPI 和 AES 加密：感知检查

Question

我正要为我目前正在开发的网站编写一个新的加密系统，如果可能的话，我想看看我是否可以在开始之前让某人对其进行感应检查！

更新： 我原来的问题应该更清楚。我需要加密一些用户数据，我还需要能够在以后的数据中读取这些数据。而且，我还需要存储用户密码或密码的哈希值，以便在登录时验证用户。

计划是：

1. 主密钥：创建一个 DPAPI 密钥设置器应用程序以获取基于文本的主密钥，通过 DPAPI 进行加密，然后将加密的输出保存到服务器上的文本文件中。这是我每次将站点移动到新服务器时都会执行的一次性任务。主密钥将用于执行 AES 加密。

2. 新用户注册时：

   2.1。保存密码数据/密码数据的哈希。

   2.2。加载主密钥文件，使用 DPAPI 解密密钥。使用解密的主密钥和每个用户数据的新随机 IV 来创建 AES 加密字符串。通过在加密字符串前加上相应的随机IV来保存每个加密字符串，并插入到数据库中的varchar列中。

3. 用户登录时：

   3.1。匹配密码哈希以验证用户。

   3.2。对于每个加密的用户数据字段，将内容分成两部分：IV 和加密数据。从 DPAPI 和 IV 中获取主密钥，解密数据并显示在屏幕上。

听起来怎么样？以上有什么明显的缺陷吗？

我是新来的，过去曾使用 Enterprise Library Security 来处理这类东西（.NET core 中不再提供它！），所以任何帮助都将不胜感激！

Answer 1

如果可以避免的话，你永远不应该存储密码。

我不清楚第 1 步中的密码是什么。如果新用户直到第 2 步才出现，这是谁的密码？

无论如何，对于您的用户来说，更好的计划是使用/保存衍生材​​料。例如，在新用户注册时执行类似

byte[] exportBytes;
byte[] exportSalt;
int exportPasswordSettingsVersion = YourSystemConfiguration.NewPasswordSettingsVersion;

using (Rfc2898DeriveBytes registerer = new Rfc2898DeriveBytes(
    newUserPassword,
    YourSystemConfiguration.GetSaltSize(exportPasswordSettingsVersion),
    YourSystemConfiguration.GetIterationCount(exportPasswordSettingsVersion)))
{
    exportSalt = registerer.Salt;

    exportBytes = registerer.GetBytes(
        YourSystemConfiguration.GetDerivedKeySize(exportPasswordSettingsVersion));
}

然后您导出盐字节（为您随机生成）、派生的密码字节、作为用户配置文件一部分的 sett。当用户登录时，您加载这些值并检查它们是否匹配：

using (Rfc2898DeriveBytes verifier = new Rfc2898DeriveBytes(
    inputPassword,
    loadedProfile.Salt,
    YourSystemConfiguration.GetIterationCount(loadedProfile.PasswordSettingsVersion)))
{
    byte[] verifyBytes = registerer.GetBytes(loadedProfile.PasswordVerify.Length);

    if (!ConstantTimeEquals(verifyBytes, loadedProfile.PasswordVerify))
    {
        return false;
    }

    if (loadedProfile.PasswordSettingsVersion < YourSystemConfiguration.GetIterationCount(exportPasswordSettingsVersion))
    {
        // Re-derive their password and save it with your newer (stronger, presumably) cryptographic settings.
    }

    return true;
}

这个方案：

• 使用 RFC2898 的 PBKDF2 算法从密码中派生密钥，存储此派生值比存储密码更好，因为如果您的凭据数据库遭到破坏，它不会泄露密码。
• 为每个新用户使用一个新的随机盐。 （也可以在密码更改或升级登录时重新生成）
• 保存（并加载）有关设置密码时使用的设置的信息，以便您以后更改默认设置。
• 不使用 DPAPI（DPAPI 还不错，但仅适用于 Windows，如果您使用的是 .NET Core，则可能需要跨平台解决方案）

Answer 2

忽略密码问题，只考虑用户数据，你的方案很好，但可以改进。

基本上，您有一个主密钥——一个对称密钥，或者可能是 16 或 32 个字节，它受到静态保护（在磁盘上），然后您在服务器上的内存中对其进行解密。

用户数据使用主密钥加密，每条数据都有一个随机 IV。请务必使用加密性强的随机数据。

您将 IV 和密文存储在一起，这很好。虽然 IV 和密文是二进制的，所以您要么必须使用 blob 数据库类型，要么使用 Base64 对二进制进行编码以将其存储为 varchar。

您应该考虑添加某种形式的篡改检测。例如，您可以使用两个主密钥——一个用于加密/解密，一个用于数据的 HMAC。您将使用加密密钥加密数据，然后在 IV + 密文上应用 HMAC（使用 HMAC 的第二个主密钥）并将 HMAC 与 IV 和密文一起存储（您甚至可以附加它）。在解密之前，您验证 HMAC。这会告诉您 IV + 密文中是否有任何内容被更改。

你没有提到填充。如果使用 AES CBC 模式，如果数据不是 16 字节的倍数，则需要填充数据。使用填充，您只需要小心不要意外提供“填充预言”，攻击者可以在其中向服务器发送任意密文，服务器的响应会告诉攻击者“填充错误”或“无效解密” " -- 即服务器响应不同。

如果您使用 AES GCM 模式，则内置 HMAC 等效项 - 您只需要单个主密钥，GCM 本身将检测密文的篡改。这还允许您包含不属于加密的“关联数据”，但包含在“身份验证”中，即就像它包含在 HMAC 中一样。例如，用户名“Joe”可以作为关联数据包含在 Joe 数据的 GCM 加密中。那么，GCM模式在解密数据时，不仅会检测到IV+密文被篡改，而且用户名还必须是“Joe”——注意这里“Joe”没有加密。

个人IV，每次随机，对于每条数据，是一个非常好的主意。您可能还会考虑在更换主密钥之前使用了多长时间。它应该有一个有限的生命周期，当它被“旋转”、“滚动”或“重新加密”（所有的意思都是一样的——你正在替换它）时，你需要某种方法来重新加密所有内容。您希望定期（可能是 3 个月，也可能是一年）更改主密钥，以 1）限制万一主密钥被泄露（例如仅 3 个月）和 2）限制暴露的数据量单个密钥用于加密的数据量（因为从技术上讲，您可以使用单个密钥加密多少数据并且在数学上仍然是“安全的”）。