许多哈希迭代：每次追加盐？
我已经使用了无声的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的唯一来源就是这个讨论 。
还有一些话题的讨论：
- HEKSbuild议
- SecurityFocus博客哈希
- Oracle密码散列algorithm的一篇论文
还有几个链接：
- PBKDF2的维基百科
- PBKDF2标准
- 一个适用的电子邮件线程
- 只是哈希是远远不够的博客文章
有很多结果。 如果你想要更多，谷歌hash stretching …有很多好的信息在那里…
除了多次重新哈希之外，我还会为每个密码/用户使用不同的salt。 虽然我认为5000次迭代太多了，但尝试一个更小的数字。 这里有一个权衡。 你将不得不根据你的需要和硬件来调整它。
对于每个密码使用不同的盐分，攻击者将被迫单独暴力破解每个密码，而不是构build彩虹表，这大大增加了工作量。
与往常一样，这是一个推荐阅读： 只是哈希是远远不够的
编辑：迭代哈希是一个完全有效的策略 。 有折衷，但一切都有它们。 如果您担心计算时间，为什么不直接存储明文密码呢？
请请不要推出自己的密码。 这就是OpenSSL这样的库。 这里有几个很好的例子，你将如何使用它来制作咸味的哈希。
在OpenSSL中使用了盐渍哈希
迭代哈希的原因是尽可能减缓进程。 所以你可以做得更好：每次迭代使用不同的盐。 可以通过在固定密钥的每次迭代中反复encryption原始数据并与salt值XORing来完成。
我更喜欢用一种含有两种不同的盐的双sha1，并且防止每次无效的密码检查递增地（简单的使用usleep）延迟答案。
