Yes.

绝对不要使用传统哈希函数的多次迭代，比如md5(md5(md5(password)))。在最好的情况下，您将获得安全方面的边际增加(这样的方案几乎不能对GPU攻击提供任何保护;直接把它输送出来。)在最坏的情况下，每次添加迭代都会减少哈希空间(从而减少安全性)。在安全性方面，明智的做法是做最坏的打算。

请使用由合格的密码学家设计的密码，该密码是有效的密码哈希，并能抵抗暴力破解和时空攻击。其中包括bcrypt、scrypt，在某些情况下还包括PBKDF2。基于glibc sha -256的散列也是可以接受的。

减少搜索空间的担忧在数学上是正确的，尽管搜索空间仍然足够大，对于所有实际目的(假设您使用盐)，在2^128。然而，由于我们谈论的是密码，根据我的粗略计算，可能的16个字符的字符串(字母数字，大写，一些符号)的数量大约是2^98。所以搜索空间减少的感觉并不是真的相关。

除此之外，从密码学的角度来说，实际上没有什么不同。

Although there is a crypto primitive called a "hash chain" -- a technique that allows you to do some cool tricks, like disclosing a signature key after it's been used, without sacrificing the integrity of the system -- given minimal time synchronization, this allows you to cleanly sidestep the problem of initial key distribution. Basically, you precompute a large set of hashes of hashes - h(h(h(h....(h(k))...))) , use the nth value to sign, after a set interval, you send out the key, and sign it using key (n-1). The recepients can now verify that you sent all the previous messages, and no one can fake your signature since the time period for which it is valid has passed.

像Bill建议的那样重新哈希几十万次只是浪费你的cpu。如果你担心别人会破坏128位，可以使用更长的密钥。

是的，重哈希减少了搜索空间，但不，这无关紧要——有效的减少是微不足道的。

重散列增加了强制执行所花费的时间，但只执行两次也是次优的。

您真正想要的是使用PBKDF2对密码进行哈希，这是一种经过验证的使用盐和迭代的安全哈希的方法。看看这个SO回应。

编辑:我几乎忘了-不要使用MD5!!!!使用现代加密哈希，如SHA-2家族(SHA-256, SHA-384和SHA-512)。

正如本文中的一些回应所建议的，在某些情况下，它可能会提高安全性，而在其他情况下，它肯定会损害安全性。有一种更好的解决方案肯定会提高安全性。不是将计算哈希的次数翻倍，而是将盐的大小翻倍，或者将哈希中使用的比特数翻倍，或者两者都做!从SHA-245跳到SHA-512。

就我个人而言，我不会为多个散列而烦恼，但我会确保也散列UserName(或另一个User ID字段)以及密码，这样两个具有相同密码的用户最终不会得到相同的散列。为了更好地度量，我可能还会在输入字符串中加入其他常数字符串。

$hashed_password = md5( "xxx" + "|" + user_name + "|" + plaintext_password);

根据我所读到的，实际上可能建议将密码重新哈希数百或数千次。

其思想是，如果您可以花费更多的时间来编码密码，那么攻击者就需要做更多的工作来进行多次猜测以破解密码。这似乎是重哈希的优势——并不是说它在密码学上更安全，而是它只是需要更长的时间来生成字典攻击。

当然，计算机一直在变得更快，所以这种优势会随着时间的推移而减弱(或者需要您增加迭代)。