@Sutherlands said:
What is the purpose of iterating a number of times, and what is supposed to change?
It's really just a waste of CPU time (and energy), but gets promoted a lot by people who either don't understand the concept of linear vs. exponential growth, or just think they're entitled to use stupid passwords and that we all need to suffer from slow logins so nobody finds out their password is "hunter2" or something.
Allowing longer/higher-entropy passwords increases the CPU cost per hash linearly (actually, since most common hash functions process input in 64-byte blocks with an 8-byte trailer, it doesn't increase at all until 56 bytes), but increases the average number of hash attempts for a brute-force attack to work exponentially. Minuscule server load, huge burden on attackers. A randomly chosen 20-character password will never be cracked before the sun burns out even if all the computers in the world were harnessed to attack it.
Using a more expensive hash function increases the CPU cost per hash linearly but doesn't increase the number of hash attempts for a brute-force attack at all, so the server and the attacker are both hurt equally. It's a stupid game to play, because bad guys have huge amounts of computational power at their disposal. If you make your hash function take an hour to evaluate, which is completely intolerable for legitimate logins, how long will a dictionary password take to brute force? Just an hour - because the attacker probably owns a botnet with as many CPUs as there are words in the English language.
Preventing a user account from getting broken into requires responsibilities from both the user and the site. The user needs to use a good password, the site needs to never expose it in plaintext. You cannot relieve the user of their part of the burden by making the hash function slow.