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)) ?

-
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. –  CodesInChaos Jul 21 '13 at 17:23
i thought rainbow tables are calculated only using known words and not from arbitrary alpha-numeric (since the hash is an alphanumeric) ? –  Abdelouahab Pp Jul 21 '13 at 17:46
That's a dictionary-rainbow. A rainbow table doesn't need to have values that 'make sense' in any language. –  rath Jul 21 '13 at 19:01
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. –  D.W. Jul 22 '13 at 3:45
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). –  rath Jul 24 '13 at 11:55

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.