Hashing SHA-512 1000 times SageMathCloud security (http://goo.gl/dCujW1) is as follows:


  Only the hash of your password is stored by the server, which uses 1000 iterations of the sha-512 hash function, with a salt length of 32.


While that does sound like a nice salt, I am a bit doubtful of the 1000-iteration idea. While this does make brute force attacks 1000 times slower, isn't it true that every extra iteration squares your chances of collision?
Baring an improbable tremendous theoretical breakthrough, any odd of any kind of collision among SHA-512 hashes, for any cause except identical input or computing failure, is negligible in practice; we'll thus handle this from a theoretical standpoint.

Let $s=512$ be the hash width; $k=1000$ the number of hash iterations; and $q&gt;0$ the number of stored iterated hashes.

The question worries about chances of collision, I assume in the stored hashes. Such collisions, even if they occurred, have little potential to help an adversary to get access or recover a password, but for the sake of the argument let's consider them anyway (say, the login system searches among all iterated hashes without using the salt as primary index).

If there was no iteration, odds of collisions would be $\approx q\cdot(q-1)/2^{s+1}$. That's also about the odds considering iterations if the salt is rehashed at each step (which is common and would match the question's statement).

With iteration and just re-hashing the previous hash, we have to worry that collisions among the result of the $q\cdot k$ total hashes could also cause a collision of the stored hashes. Because we can neglect that a cycle also gets involved and has just one of the few length that could matter, only collisions occurring after the same number of iteration need to be accounted for, and the odds of collisions among stored hashes are $\approx q\cdot(q-1)\cdot k/2^{s+1}$.

Thus with the worse possible interpretation of the question's quote, odds of collision among stored hashes grow only about linearly with the number of iterations.



The main issues to worry about:


1000 iterations is MUCH insufficient; that might have been useful when PBKDF2 was created, but no longer provides adequate protection against brute force password search in the event of a leak of the password hashes.
Better slow key derivation functions provide much better protection at equal computing cost, see scrypt.