【问题标题】:How to implement hash_hmac properly?如何正确实现 hash_hmac?
【发布时间】:2011-07-31 13:49:19
【问题描述】:

阅读this excellent answer关于密码哈希并想知道如何实现它:

The Wicked Flea 写道:

为每个用户生成一个随机数;仅此一项就击败了彩虹桌。这是一个随机数,会根据范围扩展产生的哈希值的数量。

那么除了用户密码之外,我的数据库中还要存储一个唯一的令牌?

原帖中的示例代码:

function hash_password($password, $nonce) {
  global $site_key;
  return hash_hmac('sha512', $password . $nonce, $site_key);
}

如何使用此代码验证密码?让我解释一下:

当用户提交他的密码时,我需要生成它的哈希来检查电子邮件地址 哈希密码匹配的现有数据库行。当我对用户的$nonce 一无所知时,如何选择此行?我错过了什么吗?也许我只需要通过他的电子邮件地址选择用户,然后稍后验证密码哈希?

顺便说一句,你推荐这种散列方法吗?

【问题讨论】:

  • 您不需要使用密码作为选择标准来选择用户。只需根据电子邮件地址或登录名等独特特征选择用户,然后检查密码。另请参阅有关一些散列想法的相关问题(免责声明:我对此进行了回答):stackoverflow.com/questions/3787346/…
  • 顺便说一句,仅按用户名选择还有一个优点是您可以根据错误显示“用户不存在”或“密码无效”,这极大地增加了您的可用性网站。有时您出于某种原因不得不使用不同的用户名,并且在很长一段时间后您可能会尝试使用旧的用户名和大量密码,因为它只会显示“登录失败”。如果出现“用户不存在”错误,则无需这样做
  • @Archimedix 感谢您的回复。顺便说一句,对不起,但我看不出将系统范围的盐添加到明文密码或密钥之间的区别。你能解释一下吗?
  • 无论如何我都不是加密专家,但看到你的盐是你认为你的密钥来加密用户的密码(即用户的秘密),我只会使用HMAC 密钥中的盐并将密码放入消息部分。这样,用户就不会影响 HMAC 密钥来进行差异攻击。
  • 是的,可用性增强“用户不存在”是一个安全漏洞,正如 Laas 所说的那样,因为它使攻击者能够编写有效用户帐户的列表。在这里,您可以将安全性较差的网站与也许安全性不太差的网站区分开来。然而,基于时间的攻击仍然可以用来确定哪些帐户可能是有效的,但是信心有限——对于一个拥有许多活跃用户的网站,很难说不同的加载时间是由检索不存在的用户还是由不存在的用户引起的。密码错误。

标签: php hash passwords hmac


【解决方案1】:

我认为您已经掌握了这个想法。相同的概念适用于一般的 UNIX 风格的加盐密码 - 用密码以明文形式存储 salt,并通过用户名检索它,然后使用 salt 和提供的密码生成新的哈希值,以与存储的值进行比较。

您是否信任您的数据库服务器(以及与它的连接)使用数据库支持的哈希算法并让数据库进行数学运算由您决定:

SELECT * FROM users WHERE email = 'email' AND password = SHA1(CONCAT('cleartextpass',nonce));

或者您可以在检索到所有匹配的电子邮件后在代码中进行数学运算。

编辑:ThiefMaster 关于区分丢失用户无效密码的评论是经典的安全漏洞,它允许攻击者获取列表有效用户名并专注于破解他们的密码,而不是在黑暗中钓鱼。我强烈推荐反对它。

【讨论】:

  • 你能再解释一下你的答案吗?在您的查询中,nonce 的来源尚不完全清楚。基本上你的解决方案对我来说看起来更好,因为它只能通过数据库查询来完成。
  • 在 SQL 查询中,nonce 是表列的名称(注意,它没有被引用)。这意味着 CONCAT() 获取明文密码并将其附加到存储在字段 nonce 中的内容
  • 我也可以在 SQL 和 PHP 中生成 SHA1 密钥,对吗?我可以将此 nonce 字段用于其他目的吗?丢失密码令牌等?或者这将是一个安全漏洞?
  • @fabrik - (1) 是的,只要两者都支持相同的算法(例如 MySQL 没有 HMAC),您可以在其中任何一个中生成哈希值。 (2) 这是双重的:nonce 的目的是为相同的密码获取不同的哈希值。因此,知道 nonce,攻击者可以在暴力破解时减少需要查看的字符串池。另一方面 - 攻击者只有在拥有实际密码哈希时才能从随机数中受益,在这种情况下,他可能无论如何都拥有随机数(来自 SQL 转储等)。 HMAC 通过引入 site_key 来缓解所有这些问题。
  • 我的最后一条评论不应该被阅读,我建议发送随机数 - 你总是更安全,攻击者知道的越少。
猜你喜欢
  • 2015-02-27
  • 2013-07-22
  • 2021-08-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-09-22
相关资源
最近更新 更多