密码哈希安全答案

【问题标题】：Password hashing security密码哈希安全
【发布时间】：2011-07-16 10:03:13
【问题描述】：

我有几个关于密码哈希的问题。我发现 hash_hmac 是一个很好的哈希密码函数，但仍然存在一些问题。

来自某人回答的另一个 stackoverflow 问题：

return hash_hmac('sha512', $salt . $user['password'], $this->site_key);

我最初的问题是关于 hmac 如何使用密钥，在维基百科上似乎 hmac 函数会在对每条消息进行散列之前将密钥预先添加，那么密钥本身是否不充当盐？然后我可以删除 $salt 并只使用用户特定的密钥吗？ hash_hmac('sha512', $user['password'], $this->user_key)

最大的问题仍然是 $salt（或第一个问题中的 $user_key）的生成。如果我使用 rand() 生成使用过的盐，我不喜欢将它们存储在数据库中。那么生成用户特定盐的好方法是什么？

更新

如果我将将盐存储在数据库中，是否可以安全使用：

$user_key = $user['salt'] . $this->site_key;
return hash_hmac('sha512', $user['password'], $user_key);

【问题讨论】：

为什么要使用hash_hmac() 而不是md5() 来散列密码？
@CodeInChaos: 有多少加盐密码和md5() 加密的密码因为生成速度快而被破解？我想看一篇文章。
许多低复杂度的密码。以最近的 MtGox dbleak 为例。他们使用了未加盐（旧）和加盐（新）密码哈希的组合。但即使是一些加盐密码也被破解了，因为简单的密码可以被暴力破解。拥有大量计算能力的攻击者（例如僵尸网络）每秒可以计算数十亿个 md5 哈希值。
@CodeInChaos：是的，简单的密码可以被暴力破解，但是加盐的密码甚至不是简单的。
一旦保存密码哈希的服务器受到攻击，盐也会受到攻击。这是重要的攻击场景之一。

标签： php security

【解决方案1】：

对每个用户使用随机盐并将其与哈希一起存储在数据库中。结合它是您的配置文件中的每个站点的秘密。这样一来，攻击者需要先获得对数据库和配置文件的访问权限，然后才能开始破解密码。

为了安全地散列密码，我建议结合三种成分：

一个很好的Key-Derivation-Function。它类似于普通的哈希，但它很慢并且需要加盐。 bcrypt 和 PBKDF2 是常见的选择。
每个用户的随机盐。这样做的主要目的是每个用户都不同。您将它与哈希一起存储在数据库中。如果攻击者得到它就没有问题。
每个站点的机密。这样做的目的是访问数据库并不足以破解密码。攻击者也需要访问配置文件。即使他知道了每个站点的秘密，该方案仍然像您根本没有使用秘密一样安全。

【讨论】：

根据定义假定攻击者知道盐。这就是为什么我使用每个站点的秘密以及唯一的每个用户盐。但该方案的安全性绝不能依赖于任何保密，因为整个服务器可能会受到损害。
@Shef 盐的目的是防止使用彩虹表来反转密码哈希。它不是散列的“关键”或类似的东西，散列没有“关键”。需要很长时间才能找到盐渍哈希的冲突，这就是主要目的。你需要知道salt，所以如果你的服务器被入侵，攻击者也可以找到它。无需特意隐藏盐分。这样做通常只会对攻击者造成轻微的减速。
@Shef、deceze 和 CodeInChaos 是对的；您的 cmets 不正确。盐（应该是每个用户）不是散列的关键。即使知道哈希和密钥，恢复密码仍然需要大量计算。目的是让攻击者（在设想的场景中已经拥有数据库中的所有数据）分别攻击每个哈希。普通rainbow attacks（用户之间共享工作）无法使用。

【解决方案2】：

使用 bcrypt！

关于安全存储密码的经典文本：

http://codahale.com/how-to-safely-store-a-password/

引用文章：

盐对你没有帮助

奖金！

使用 bcrypt 比使用自己的 bs 更简单，而且可能是不正确的加盐方案。

永远不要实现自己的加密系统或熵源

【讨论】：

盐当然有帮助，但仅靠盐是不够的。使用唯一的每用户盐可以防止攻击者同时攻击数据库中的所有哈希。因此，如果您的数据库有 n 个条目，那么与没有每个用户 salts 的数据库相比，使用 salts 的数据库会使攻击者的速度降低 n 倍。这就是为什么任何好的散列方案都使用慢操作模式和盐的原因。