in reply to Opportunity to excel
in thread Status of Recent User Information Leak
Making the hash algorithm really slow makes the hash unusable in most practical situations. If you need two seconds on a fast machine for the hash to compute, login to a website would make the server unresponsive for two seconds. Everyone could do a denial-of-service attack to that website by simply doing one (failed) login attempt per second!
Also rainbow tables will find good passwords with the same chance as dumb passwords. Rainbow tables are precomputed lists. For every entry you hash a random password, then hash the resulting hash, and so on for (lets say) 100000 times. Store the last hash as key and the starting password as data in your database. Now do this precomputation for a year or so
If you now want to crack a hash, just hash it, then hash the resulting hash and so on until you find a hash that corresponds to a key in your database. If you find one after rehashing less than 100000 times you have a winner. Now you only need to use the starting password of that database entry and do the rehash cycle from there again until you find the value in the chain just before the hash you got. That is your password (in reality always a collision with the original password).
So rainbow tables in fact allow a costly brute force search, because you need to do it only once for a specific hash algorithm and can do it in preparation for the actual cracking.
The often mentioned seeding does not prevent rainbow tables but makes them expensive again because you need a separate rainbow table for each individual seed value.