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

Question

我已经长时间使用了无盐的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;

我首先想要使用第二个版本(追加一次)但后来发现每次添加盐的一些脚本.

所以,我想知道每次添加它是否会增加哈希的强度.例如,攻击者是否有可能找到一种聪明的方法来创建一个100XSha512函数,这比简单地执行sha512 100倍？

Answer 1

简而言之:是的.转到第一个例子......如果反馈给自己而不添加原始数据,哈希函数可能会丢失熵(我现在似乎无法找到引用,我会继续查看).

为了记录,我多次支持哈希.

生成需要500毫秒的哈希对于您的服务器而言并不太慢(考虑到生成哈希通常不会在绝大多数请求中完成).然而,花费那么长的哈希将显着增加生成彩虹表所需的时间......

是的,它确实暴露了DOS漏洞,但它也可以防止暴力攻击(或者至少使它们过于缓慢).绝对是一种权衡,但对某些人来说,这些好处超过了风险......

整个过程的参考(更像是概述):密钥强化

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

还有一些关于这个主题的讨论:

1. HEKS提案
2. 关于散列的SecurityFocus博客
3. 关于Oracle密码散列算法的论文

还有一些链接:

1. WikiPedia上的PBKDF2
2. PBKDF2标准
3. 适用的电子邮件主题
4. 只是哈希远远不够博客文章

有很多结果.如果你想要更多,谷歌hash stretching......有很多好消息......

Answer 2

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

对于每个密码使用不同的盐,攻击者将被迫单独强制使用每个密码而不是构建彩虹表,这大大增加了工作量.

和往常一样,这是一个推荐读物:只是散列远远不够

编辑:迭代哈希是一个非常有效的策略.有权衡,但一切都有它们.如果您担心计算时间,为什么不直接存储明文密码？