That's the crux of the problem. Hashes that are good for fingerprinting files (MD5, SHA-n) aren't good for keeping passwords secure, because they need to be fast. Your idea seems fine, but you're forgetting the "first rule of implementing crypto primitives": don't do it! (http://www.letsyouandhimfight.com/2010/07/14/cl-bcrypt-a-fir...)
Nonsense. I am well aware of the problem with hash functions.
First off; it is not a primitive, but a protocol, it is still a bad idea to design those yourself. But they are not; they are getting the advice of an expert.
Secondly; this is in a specific scenario where you are left only with the fast digests (shockingly, this is still a common situation). Introducing an "artificial" slow factor is accepted practice.
Thirdly; this is definitely not my idea. The iteration suggestion was from tptacek who months ago answered a similar question to this with something along the lines of "if you must insist on using fast hashing for gods sake iterate it a number of times" (I can't find the quote off hand, it was some time ago, but I entirely agree). The rotating random salt is an old old idea.
It's very easy to recite the mantra "always use bcrypt, follow the first rule of crypto, digests are evil", but it's even harder to use that knowledge in practice, I find. :)
You can introduce slowing factors like seed values and iterations (bcrypt uses both) but they're a bad idea if you're doing it yourself. For example, your initial estimate of 50 iterations is at least a couple of orders of magnitude out. How many is safe? 10,000? 100,000?
BTW, I'd be interested to know exactly what this mythical situation is where you're handling user accounts, but don't have access to one of the existing bycrypt implementations (C, Ruby, Python, PHP) and can't compile your own.
It's not really a primitive, but I'll concede the point. Similarly the one about 50 iterations, that was somewhat silly (there is a reason I have that number in mind, but I won't bore with details).
However. Mythical situation? Try a good portion of shared PHP hosting; why do you think the most popular software in the world (i.e. stuff like Wordpress) still supports MD5/Sha hashing?
I realise this is not a problem you may have come across before; but don't imagine it does not exist :)
So use PHP-ass: http://www.openwall.com/phpass/. It's integrated into Wordpress and does all of that stuff, including falling back to md5 if you have a really crappy host.
But really - it's just another reason not to use PHP, and not to have a crappy webhost. You could probably say much the same things about backups, app security, bad UI or design. But for most people, don't do that is apparently not a good enough answer.
Update: Just looking into how Django stores passwords, and it does much the same thing (although it falls back to SHA-1, rather than MD5). There was a push to use bcrypt a while back, but it got marked wontfix, due to "backwards compatibility issues". Sigh.
That's the crux of the problem. Hashes that are good for fingerprinting files (MD5, SHA-n) aren't good for keeping passwords secure, because they need to be fast. Your idea seems fine, but you're forgetting the "first rule of implementing crypto primitives": don't do it! (http://www.letsyouandhimfight.com/2010/07/14/cl-bcrypt-a-fir...)