许多哈希迭代:每次追加盐?

我已经使用了无声的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; 

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

所以,我想知道是否每次添加它都会给哈希增加一些实力。 例如,攻击者是否有可能find一些聪明的方法来创build一个100倍的SHA512函数,而这个函数的执行速度比简单地执行一次sha512要快100倍?

    总之:是的。 去第一个例子…哈希函数可以丢失熵如果反馈到自己而不添加原始数据(我现在似乎无法find一个参考,我会继续寻找)。

    而为了logging,我多次支持哈希。

    对于您的服务器,生成500毫秒的散列速度不算太慢(考虑到生成散列通常不是绝大多数的请求)。 然而,花费这么长时间的散列会大大增加生成彩虹表所需的时间。

    是的,它确实暴露了一个DOS漏洞,但是它也可以防止powershell攻击(或者至less使它们变得非常慢)。 这绝对是一个权衡,但是对一些利益超过风险…

    对整个过程的参考(更像概述): 关键加强

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

    还有一些话题的讨论:

    1. HEKSbuild议
    2. SecurityFocus博客哈希
    3. Oracle密码散列algorithm的一篇论文

    还有几个链接:

    1. PBKDF2的维基百科
    2. PBKDF2标准
    3. 一个适用的电子邮件线程
    4. 只是哈希是远远不够的博客文章

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

    除了多次重新哈希之外,我还会为每个密码/用户使用不同的salt。 虽然我认为5000次迭代太多了,但尝试一个更小的数字。 这里有一个权衡。 你将不得不根据你的需要和硬件来调整它。

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

    与往常一样,这是一个推荐阅读: 只是哈希是远远不够的

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

    请请不要推出自己的密码。 这就是OpenSSL这样的库。 这里有几个很好的例子,你将如何使用它来制作咸味的哈希。

    在OpenSSL中使用了盐渍哈希

    迭代哈希的原因是尽可能减缓进程。 所以你可以做得更好:每次迭代使用不同的盐。 可以通过在固定密钥的每次迭代中反复encryption原始数据并与salt值XORing来完成。

    我更喜欢用一种含有两种不同的盐的双sha1,并且防止每次无效的密码检查递增地(简单的使用usleep)延迟答案。