多次哈希迭代:每次都附加盐?

2022-08-30 12:42:11

我已经使用无盐的md5 / sha1很长时间了,但是由于这种方法并不真正安全(并且随着时间的推移变得越来越不安全),我决定切换到盐渍sha512。此外,我想通过使用多次迭代(例如100)来减慢哈希的生成速度。

我的问题是,我是应该在每次迭代时都附加盐,还是在开始时只附加一次盐。以下是两个可能的代码:

每次追加:

// some nice big salt
$salt = hash($algorithm, $salt);

// apply $algorithm $runs times for slowdown
while ($runs--) {
    $string = hash($algorithm, $string . $salt, $raw);
}

return $string;

追加一次:

// add some nice big salt
$string .= hash($algorithm, $salt);

// apply $algorithm $runs times for slowdown
while ($runs--) {
    $string = hash($algorithm, $string, $raw);
}

return $string;

我首先想使用第二个版本(附加一次),但后来发现一些脚本每次都附加盐。

因此,我想知道每次添加它是否都会为哈希值增加一些强度。例如,攻击者是否有可能找到一些聪明的方法来创建一个100timesSha512函数,这比简单地执行sha512 100次要快得多?


答案 1

简而言之:是的。使用第一个示例...如果在不添加原始数据的情况下反馈到自身,哈希函数可能会失去熵(我现在似乎找不到参考,我会继续寻找)。

为了记录在案,我支持多次散列。

生成需要 500 毫秒的哈希对于服务器来说不会太慢(考虑到生成哈希通常不会在绝大多数请求中完成)。但是,需要这么长时间的哈希值将大大增加生成彩虹表所需的时间......

是的,它确实暴露了DOS漏洞,但它也可以防止暴力攻击(或者至少使它们变得非常慢)。绝对有一个权衡,但对一些人来说,好处超过风险......

对整个过程的引用(更像是概述):关键强化

至于退化的碰撞,到目前为止我能找到的唯一来源就是这个讨论......

关于这个话题的更多讨论:

  1. 赫克斯提案
  2. 安全性关注散列博客
  3. 一篇关于 Oracle 密码哈希算法的论文

还有几个链接:

  1. PBKDF2在维基百科上
  2. PBKDF2 标准
  3. 适用的电子邮件线程
  4. 只是散列远远不够博客文章

有大量的结果。如果你想要更多,谷歌...那里有很多好的信息...hash stretching


答案 2

除了多次重新散列它之外,我还会为每个密码/用户使用不同的盐。虽然我认为5000次迭代有点太多了,但请尝试较低的数字。这里有一个权衡;您必须根据需要和硬件进行调整。

由于每个密码都有不同的盐,攻击者将被迫单独暴力破解每个密码,而不是构建彩虹表,这大大增加了工作量。

与往常一样,这里有一个推荐的阅读:只是散列是远远不够的

编辑:迭代哈希是一种完全有效的策略。有权衡,但一切都有。如果您担心计算时间,为什么不直接存储明文密码呢?


推荐