存储可解密密码的安全方法答案

【问题标题】：Safe way to store decryptable passwords存储可解密密码的安全方法
【发布时间】：2011-02-03 02:28:04
【问题描述】：

我正在用 PHP 制作一个应用程序，并且要求必须可以解密密码，以避免将来将用户数据库切换到不同的系统时出现问题。考虑到无法修改这个未来系统的密码方法，我需要纯文本密码才能生成密码。

计划是使用存储在服务器上的公钥加密用户的密码。身份验证是通过加密输入和比较结果来完成的。没有完成解密。能够解密的私钥存储在异地以供以后使用。

您建议使用哪种加密/解密算法？当您认为攻击者无法使用私钥时，加密的密码是否仍与散列 (MD5/SHA1) 一样安全？

【问题讨论】：

MD5 和 SHA1 不是加密，而是散列。您在这里谈论的是加密还是散列？
@Matti Virkkunen 和 erenon：问题是“密码是否仍然像 MD5/SHA1 一样安全”......当存储了可解密的密码但私钥是存储在其他地方（网络服务器完全无法访问？）
@VolkerK 我不知道您为什么要使用非对称加密来存储密码。这违反了 CWE-257。
如果服务器可以访问密钥（它需要验证密码），那么其他任何人也可以获得访问权。
"如果您需要更改密码存储系统，那么您可以在用户下次登录时更新密码哈希。"

标签： php security passwords password-encryption

【解决方案1】：

我将改写 Jammer 的方法 -

生成公钥/私钥对。在您的网络服务器上硬编码公钥。将私钥存储在网络服务器/数据库/任何开发人员无法触及的实体银行储物柜中。
用户注册时，使用公钥加密密码+盐。此步骤与使用哈希算法相同。将加密的密码+盐存储在数据库中。
当您要验证密码时，再次对其进行加密，并将其与数据库中存储的值进行比较。

如果攻击者获得了数据库，他就无法解密密码，因为他没有私钥。他无法获得私钥，因为它在他无法触及的银行保险库中。由于盐的原因，两个相同的密码仍然会以不同的方式存储在数据库中。

我不建议使用上述方法，因为在未来的任何时间点都可能有人滥用私钥并获得所有密码的访问权限。

但是，如果您保证私钥将始终保持私密，那么我看不出存在技术缺陷。

当然，我可能是错的。

【讨论】：

与仅散列密码相比，它在处理方面也相当昂贵。
@Sripathi 正确，但我应该使用什么算法？
@symcbean 它可能更贵，但我认为这不会成为问题。此外，任何攻击者在对数据库执行字典攻击时都必须花费更多时间。
确实，建议使用 bcrypt 对密码进行哈希处理的原因是它的设计速度很慢。
@Jammer - 你应该阅读这个线程中的讨论 - stackoverflow.com/questions/2283937/…。这是一个漫长的讨论，但与您的问题非常相关。

【解决方案2】：

不要解密密码。如果您以后需要更改密码系统，请添加一个名为 storage_type 的字段（或其他）。

然后，当您需要更改密码时，您将检查它是否是旧密码。如果是，下次他们登录时，您可以更改密码编码。否则，请使用新系统登录。

【讨论】：

【解决方案3】：

能够解密密码是个坏主意（而且可能没有比不加密存储更好的方法了）。如果您更改存储方法，您的主要问题似乎是能够使用密码。只需做 Linux 所做的事情，存储您如何使用密码对密码进行哈希处理。因此，例如 $1$salt$hash 是 MD5。这样，如果您决定更改密码的存储方式，您仍然可以检查旧密码（如果有人正确登录，您可以使用新哈希更新他们的密码）。

【讨论】：

这需要我修改未来的平台，我宁愿不这样做。当然，将普通密码也移到那里也需要一些努力，但至少在一次性移动后不需要任何管理工作。
您不能使用您知道将来会支持的东西吗？例如，SHA512 在几乎任何平台上都很容易做到（如果你能找到一个库来做加密，你可能也可以做 sha512）。
我同意，您不应该为了更容易切换到 next 加密方法而牺牲安全性。一开始就从一个好的开始，你不需要太在意未来的任何变化。

【解决方案4】：

我看到的唯一问题是，大多数公私钥加密代码将使用公钥加密对称密钥，并依靠私钥解密，然后使用对称密钥加密消息。

你想用公钥直接加密密码+salt。

因此，针对您的系统的攻击归结为：

对通用公钥/私钥加密的攻击
对您的私钥存储的攻击。

【讨论】：

【解决方案5】：

对于大多数应用程序来说，存储密码的 SHA-1 哈希就足够了。

是的，在大多数哈希算法中都存在已知的冲突，但这并不意味着实际的攻击向量。尤其是当你给哈希加盐的时候。

对于您的 salt：将其存储在一个配置文件中，该配置文件不能从外部访问，但可以由您的 PHP 安装读取。

【讨论】：

-1 你提出的是一个公认的漏洞。我们在 BugTraq 上见。
我正在寻找加密解决方案，而不是散列。
存储一个盐只比不使用一个好一点，为每个密码使用一个盐是一个更好的主意。
这完全取决于您实际需要多少安全性。正如我所说：对于大多数应用程序，简单的加盐哈希就足够了。遗憾的是，许多应用程序也充满了自身的安全问题，以至于不太完美的哈希算法是它们的问题中最少的。