安全地存储无法加密的凭据

Question

我有一个正在运行来自多个帐户的信息汇总器的客户端。 数据库需要以其他方式将用户名和密码存储到其他网站，脚本以后可以使用该方式登录到那些网站以检索数据。

我认为与其将它们存储为纯文本，不如将其哈希存储。 显然，如果某人可以访问代码和数据库，那么他们仍然可以访问纯文本版本，但如果只有一个或另一个，则不能访问纯文本版本。

还有更好的主意吗？

Answer 1

如果系统要求用户输入密码，则可以使用该密码生成密钥来加密/解密其他网站的密码。

这样，您需要用户输入该密码才能解密您存储在数据库中的密码。

这里有更详细的流程：

1. 用户登录系统时输入密码“ 123456”。
2. 您使用“ 123456”密码的SHA256并获得一个密钥：“ 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020cc923adc6c92”
3. 使用该“ 8d969 ...”密钥使用AES解密数据库中站点的密码。

您可以通过多种方式对此进行优化。 例如：在计算SHA哈希之前先对密码加盐。

作为此类盐腌的实际示例， Michael建议使用PBKDF2 （将HMAC - SHA-256作为其两个参数伪随机函数）。

其他增强功能：存储密钥的加密版本，以允许您的用户更改自己的密码，而不必重新加密其所有密码...等等...

Answer 2

您可以使用凭据进行任何操作，攻击者也可以

混淆实际上能买到什么？ 时间。 毕竟，数据就在那里，您自己使用它的方案也是如此。 有人弄清楚您的方案只是时间问题。 这一切都取决于您的偏执程度以及对您所适应的风险程度的评估。 特别是，如何存储任何凭据应取决于谁有权访问运行数据库的计算机。

最终，橡胶必须上路，所以继续前进并征服它。 不要完全敲打混淆。 只要确保将其与明智的做法相结合即可。

方法与建议

为每个帐户生成每个应用程序的API密钥，以供计算机使用

如果您可以从第三方帐户生成API密钥，则可以在不关闭所有潜在应用程序的情况下撤消对帐户的访问权限。 许多服务都具有这些类型的API密钥（Google，Twitter，StackExchange，Facebook等）。

您只需设置一个“应用程序”，然后使用使用者密钥和机密以及访问令牌和访问机密。 机器只需要存储这些凭据。 如果发生折衷，您只需撤销该组键即可。 此外，这些允许您指定每个帐户的权限。

使用每个用户的密码作为其凭据集

用户登录后，才可以解锁他们的密码集。 为此，您将基于适当的哈希方案和验证检查生成密钥，该检查在密钥之前进行了多个哈希步骤。

无论如何都将其加密在磁盘上

您始终可以使用一个密钥来加密凭据。 这样，您只有一个密钥可以保护（保护所有其他秘密）。 然后，您将必须解密才能访问其他凭据。

将机密存储在系统的密钥环中

在Linux上，使用gnome-keyring 。 然后，您可以进行简单的Create-Read-Update-Delete调用，将其视为密码数据库。 Gnome密钥环基于PKCS＃11标准。

gnome-keyring具有一个API，用于保存到密钥环和检索项目。

/* A callback called when the operation completes */
static void
found_password (GnomeKeyringResult res, const gchar* password, gpointer user_data)
{
  /* user_data will be the same as was passed to gnome_keyring_find_password() */
  // ... do something with the password ...
  /* Once this function returns |password| will be freed */
}

static void
find_my_password()
{
  gnome_keyring_find_password (GNOME_KEYRING_NETWORK_PASSWORD,  /* The password type */
                               found_password,                  /* callback */
                               NULL, NULL,     /* User data for callback, and destroy notify */
                               "user", "me", 
                               "server", "gnome.org",
                               NULL);
}

在Windows 7+上，使用“加密文件系统”（EFS）功能。 所有文件均使用证书进行加密，依次使用Windows密码进行保护。

但是，不要让这种情况使您陷入一种错误的安全感。 如果这是一台正在运行的服务器，则如果有人可以通过网络访问该设备，那么他们也可以自己访问密钥环数据。

设置授予访问权限的远程计算机

您是否可以设置一台可以使用公钥和私钥对授予凭据或解锁密钥访问权限的计算机？

关于哈希

如果您对用户名和密码进行哈希处理，则不会找回它们。 哈希被设计为单向函数。

您可以对数据进行编码以进行混淆，但是我不建议这样做。

Answer 3

如果对信息进行散列，则以后将无法检索它。 如果对其进行加密，则需要将密钥存储在某处。 除了从物理上限制对数据库的访问之外，没有可靠的方法来消除恶意使用数据的可能性。

散列可以以所有可预见的方式阻止使用原始数据。 但是，您需要使用数据。 像SHA-256这样的密码哈希被设计成使得在给定H(m)情况下很难找到计算m方法（不生成大小不合理的查找表），其中H是您最喜欢的哈希函数。

如果走加密路线，则需要存储加密密钥，并且它可能会受到威胁或至少用作解密预言。 您可以使服务代理为您执行解密，并同时使用客户端和服务器身份验证证书来确保安全。 但是，如果有人泄露了授权的客户，则您在泄露和发现帐户可能遭到泄露之间有一段时间间隔。 但是，这种方法使您可以灵活地撤销证书并立即拒绝服务器访问，即使您再也无法访问受感染的客户端。

我建议设置一个远程服务，该服务仅可通过直接连接（在同一物理交换机上）使用，并且必须向客户端进行身份验证并要求所有客户端进行身份验证。 如果要让客户受到损害，也许限制它可以进行的查询数量也将有助于防止滥用。 该服务将需要针对每个请求检查证书吊销。

该服务还需要连接到远程日志记录设施，该设施将用于独立审核系统。 此日志记录服务需要再次对客户端进行身份验证，并向客户端进行身份验证。 日志记录服务接收数据并将其附加到日志，它永远不允许修改或删除。 收到日志条目后，它将对带时间戳的日志条目进行数字签名，然后将其输入审核容器。

这类似于证书颁发机构设置其纸质记录以审核证书颁发的方式，以便为折衷方案提供最佳的恢复模型，因为实际上防止折衷方案是不可能的。