许多哈希迭代:每次都添加盐? [英] Many hash iterations: append salt every time?

查看:41
本文介绍了许多哈希迭代:每次都添加盐?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用未加盐的 md5/sha1 已经很长时间了,但由于这种方法并不安全(而且随着时间的推移变得更不安全),我决定改用加盐的 sha512.此外,我想通过使用多次迭代(例如 100)来减慢哈希的生成速度.

I have used unsalted md5/sha1 for long time, but as this method isn't really secure (and is getting even less secure as time goes by) I decided to switch to a salted sha512. Furthermore I want to slow the generation of the hash down by using many iterations (e.g. 100).

我的问题是我应该在每次迭代时添加盐还是只在开始时添加一次.这是两个可能的代码:

My question is whether I should append the salt on every iteration or only once at the beginning. Here are the two possible codes:

每次追加:

// 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;

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

I first wanted to use the second version (append once) but then found some scripts appending the salt every time.

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

So, I wonder whether adding it every time adds some strength to the hash. For example, would it be possible that an attacker found some clever way to create a 100timesSha512 function which were way faster than simply executing sha512 100 times?

推荐答案

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

In short: Yes. Go with the first example... The hash function can lose entropy if feed back to itself without adding the original data (I can't seem to find a reference now, I'll keep looking).

为了记录,我支持多次散列.

And for the record, I am in support of hashing multiple times.

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

A hash that takes 500 ms to generate is not too slow for your server (considering that generating hashes are typically not done the vast majority of requests). However a hash that takes that long will significantly increase the time it will take to generate a rainbow table...

是的,它确实暴露了 DOS 漏洞,但它也可以防止蛮力攻击(或至少使它们慢得令人望而却步).这绝对是一种权衡,但对某些人来说,收益大于风险...

Yes, it does expose a DOS vulnerability, but it also prevents brute force attacks (or at least makes them prohibitively slow). There is absolutely a tradeoff, but to some the benefits exceed the risks...

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

A reference (more like an overview) to the entire process: Key Strengthening

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

As for the degenerating collisions, the only source I could find so far is this discussion...

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

And some more discussion on the topic:

  1. HEKS 提案
  2. 关于哈希的 SecurityFocus 博客
  3. 一篇关于 Oracle 密码哈希算法的论文莉>

还有一些链接:

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

有大量的结果.如果你想要更多,谷歌哈希拉伸...那里有大量的好信息...

There are tons of results. If you want more, Google hash stretching... There's tons of good information out there...

这篇关于许多哈希迭代:每次都添加盐?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆