使用密码哈希加密私钥答案

【问题标题】：Using hash of password to encrypt private key使用密码哈希加密私钥
【发布时间】：2012-08-02 07:12:22
【问题描述】：

我正在开发一个需要加密敏感信息的 Web 应用程序。我的计划是使用 AES-256，其中私钥由用户密码的哈希加密。我需要存储密码的哈希以进行身份验证，但显然不能用于加密私钥。我目前的想法是使用 bcrypt 生成用于加密私钥的密钥。对于身份验证，我的想法是简单地使用 bcrypt 散列密码，然后再次使用 bcrypt 散列该散列，然后将该散列存储在数据库中。既然是一种方式，就不应该有任何方式使用存储的哈希来解密私钥吗？这样做是否存在我可能遗漏的明显安全问题？

我的另一个想法是使用两种不同的加密算法，例如使用 bcrypt 散列来加密私钥并存储 SHA-2 散列用于身份验证。

感谢您的帮助。

【问题讨论】：

如果这里没有人能给你一个明确的答案，你不妨试试crypto.stackexchange.com

标签： security encryption hash

【解决方案1】：

一个建议：使用两种不同的盐。当用户输入他们的密码时，将其与随机盐连接并对其进行哈希处理以用于密码识别例程。使用不同盐并再次对 AES 加密密钥进行哈希处理。根据您想要的安全程度，您也可以扩展散列。

实际上你有：

storedPasswordCheck = SHA256(password + salt1);

AESkey = SHA256(password + salt2);

AES 密钥当然不会被存储，而是根据需要从用户密码中重新生成。您需要为每个用户存储两个单独的盐，最好每个至少 128 位。

【讨论】：

（抱歉删除了评论，我误读了您的答案；+1）——但我要提到的是，将哈希转换应用于源密码并不会为您提供比使用用户的密码直接在哈希中。也就是说，散列函数不能产生比用户原始密码更多的熵。（这适用于任何散列函数）
我几乎不认为你需要 AES 密钥上的盐——密码仍然不是以纯文本形式保存的。
密码并不总是安全的，用户倾向于选择他们能记住的东西。加盐的、散列的（并且可能是拉伸的）密码将具有更少的弱点。为了安全起见，稍微矫枉过正也不是坏事。
它的弱点如何减少？加盐是为了使从哈希中恢复密码变得困难。但是哈希并没有存储在这里，它只是用作 AES 的输入。
人们会选择容易猜到的密码："secret"、qwertyuiop"、"password123"。他们也会选择容易记住的密码，这些密码很容易被字典中的所有单词尝试。有密码密码破解程序它利用这些漏洞。哈希可以防止这种情况，而盐可以防止轻松使用预先准备好的彩虹表和其他离线攻击。拉伸可以尽可能地减慢任何攻击者的速度。

【解决方案2】：

不要使用哈希来加密 AES 密码。 salted hash 应该只用于身份验证。当用户登录时，您有他的密码。使用此密码加密（第一次）和解密（稍后）AES 密钥，然后忘记密码。

【讨论】：

【解决方案3】：

我建议在这种情况下使用PBKDF2。您可以使用两种不同的盐，一种会派生对称密钥，另一种会派生要存储的密码哈希。盐应该包含区分两个不同用例的确定性部分，以及随机部分 - 参见。此评论：

否则，盐应该包含明确的数据区分不同的操作和不同的key 长度，除了至少为八的随机部分八位字节长，此数据应由以下人员检查或重新生成接受盐的一方。例如，盐可能有一个额外的非随机八位字节，指定的目的派生的密钥。或者，它可以是一个编码指定有关派生的详细信息的结构密钥，例如加密或身份验证技术和不同密钥之间的序列号密码。附加数据的特定格式被留下到应用程序。

正如 cmets 中提到的那样，由于典型密码的熵很差，因此普通的加盐 SHA-2 可能还不够。

【讨论】：