I think the conventional wisdom is that you should not re-invent security. I am slowly learning this, but the give-away seems to be questions that start with "Couldn't you just..."
It also was conventional wisdom that banks were too big to fail ;)
Are there any actual arguments against using this as an 'easy' fix to the precomputed rainbow tables scenario? Multiple rounds of a cipher seem to be a relatively common operation in crypto and have helped other old ciphers. One of the more prominent ones would probably be the move from DES to triple DES.
I guess dictionary attacks on GPUs would still be easy enough, even with more iterations, but anything that isn't directly in a dictionary might benefit quite a bit from multiple iterations.
It's not as good as actually using proper crypto rather than hashing algorithms that were designed to be fast, but it seems like an easy to implement low-risk solution.
I am no security expert. I can't tell bcrypt from a hole in the ground. All I know is that it's all fun and games until there is a problem with this home-brew implementation and then it's too late. That is why I think it's best to avoid anything like this and instead go with bcrypt/scrypt, etc. and re-evaluate periodically based on latest industry standards. Perhaps an actual security expert on here can evaluate your idea. I seem to remember it being raised many times on here, so there may be an answer to this on one of the discussions of bcrypt vs scrypt or some such.
One would just check against a top10[000…] list of passwords on which various multiple hash combinations had been applied md5(md5(md5(md5('password')))) is going to be easy to reveal.
Your system would seem to be practical if you know there are no weak passwords or if you dont care if only some of the accounts are compromised.
Is the "easily detected" part really a problem? The idea isn't to try security by obscurity.
The main advantage is that it would still keep people from using precomputed rainbow tables and slow down brute force attacks with a minimum of additional code, wouldn't it?
(similar to the switch from DES to triple DES back in the day)
Couldn't you just run your whole database through X more rounds of MD5 and do the same in your authentication function?
That way, script kiddies couldn't use precomputed rainbow tables they downloaded somewhere off Bittorrent.
Each additional round will also reduce the speed of a brute force attack while still keeping the changes to the codebase will be pretty small.
Unless there are rainbow tables for a certain number of MD5 iterations, it would be a start...