Why do people say that using hash twice or more is bad? yes there is key derivation that do that job, but in a low bandwidth network countries, the solution i see is to use a simple hashing system on the server to gain one second or two.

Is rainbow table effective when using more than one hash? because on internet, i only find MD5 or SHA tables, so i guess that the algorithm will work only on hash(str) and will not work on hash(hash(str)) ?

  • 2
    $\begingroup$ If you're talking about password hashing then it's bad because it doesn't have a salt (which needs to different for each user) and it's bad because it's fast. Rainbow tables are largely irrelevant, what's the real threat are GPUs. Without salt all hashes in a database can be attacked at once, with salt they need to be attacked individually. $\endgroup$ Commented Jul 21, 2013 at 17:23
  • $\begingroup$ i thought rainbow tables are calculated only using known words and not from arbitrary alpha-numeric (since the hash is an alphanumeric) ? $\endgroup$ Commented Jul 21, 2013 at 17:46
  • 1
    $\begingroup$ That's a dictionary-rainbow. A rainbow table doesn't need to have values that 'make sense' in any language. $\endgroup$
    – rath
    Commented Jul 21, 2013 at 19:01
  • 1
    $\begingroup$ Your question starts from the premise that hashing twice is "bad". Where did you get that impression from? Why do you think it is "bad"? Do you have a citation? The answer is most likely to be much more nuanced: e.g., that for some problems, hashing twice is not sufficient (not that it's somehow always "bad"). I think you need to specify the context in which you are using a hash, and what you are using the hash for (password hashing? key derivation? collision-resistance? something else?). Otherwise, this question is simply too broad to be answerable. $\endgroup$
    – D.W.
    Commented Jul 22, 2013 at 3:45
  • 1
    $\begingroup$ I don't see how network bandwidth affects hashing. Adding recursion does not significantly increase computation effort (you'd need at least a few thousand recursion levels and a GPU can crunch through that anyway). $\endgroup$
    – rath
    Commented Jul 24, 2013 at 11:55

1 Answer 1


This call for a few different answers.

  1. First concerning any rainbow table or similar approach, nothing prevents you from defining $HH(x)=H(H(x))$ and then to apply the desired method to the composed function $HH$. Even if $HH$ has slightly different properties from a usual hash function (see below), this will still work fine. So you gain no additional protection here.
  2. If you are concerned by collisions, you should be aware that the probability of collision is slightly higher with a repeated hash, indeed, a collision $HH(x)=HH(y)$ with $x\neq y$ may arise in two different ways (either $H(x)=H(y)$ or $H(x)\neq H(y)$ and $H(H(x))=H(H(y))$. This almost doubles the probability of collision for a given pair $\approx 2^{1-h}$ instead of $2^{-h}$.
  3. If you want to consider a more theoretical approach, you should look at To Hash or Not to Hash Again? (In)differentiability Results for H^2 and HMAC (http://eprint.iacr.org/2013/382), which shows that $HH$ is not indifferentiable from a random oracle.
  • $\begingroup$ ah! thank you! so i think i should adopt a KDF with small rounds and salt :) $\endgroup$ Commented Jul 21, 2013 at 20:41
  • 2
    $\begingroup$ @AbdelouahabPp If you hash passwords you should use a KDF with many rounds, not few rounds. Fast KDFs are useful if your master key is already strong. $\endgroup$ Commented Jul 24, 2013 at 7:26
  • $\begingroup$ @CodesInChaos thank you, on python here, the better i can put on pbkdf2-sha512 (on 64 bits machine) is 10000, even if owasp suggests a big value :( $\endgroup$ Commented Jul 24, 2013 at 10:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.