I think what he's suggesting is composing secure hash functions with some simple customisable steps, like xor, negation, so that the final result is as secure as scrypt, bcrypt, what have you, but also customized, so that standard tools won't work, and the attacker would have to do some custom legwork to attack your application. This, done correctly, would increase the cost of attacking to the point of making drive-by, mass-trolling attacks uneconomical, as they're based on pointing an exploit tool at a list of adresses.
It will not deter targeted attacks (spearfishing) by competent attackers, but again, not much would.
The idea that my customizations would make it appreciably more secure (especially vs. just slightly increasing the work factor) seems questionable to me. On the other hand, it's very plausible that my customizations could accidentally make it less secure. Way smarter folks than me have messed up algorithms they actually put a lot of thought into — I'm not going to go blithely turning knobs in good algorithms and hope their positions weren't important.
Incidentally, what kind of drive-by attack are you thinking? Like, you have your password database sitting out in the open and there are bots crawling the web trying mechanically to crack it? Because that doesn't sound like a common case, but I'm not sure what else you could mean.
This comment was factually incorrect and only served to cloud the issue. The link given in one of the responses provides more than enough information for a developer to understand the options available for password storage.
bcrypt in and of itself already uses multiple runs to make it expensive in terms of CPU time to reproduce a given password. Moreover, salts are precisely designed to help against rainbow table attacks by making it infeasible to create rainbow tables including the large number of salts that you tag onto the end of a given password. bcrypt includes a salt as part of its core.
So no, if your scheme is “simply” bcrypt(password), it will not take so short a time for someone to extract passwords from rainbow tables, because they won't be able to have rainbow tables. Proper rainbow tables would need to both account for the salt and the number of encoding runs your bcrypt function has (which, incidentally, is also a configurable value).
Yes, you're completely right. I was actually trying to illustrate the "tweakable knobs" concept in bcrypt in my nested example but I can see that my explanation was not helpful, and served to confuse the issue.
For one, salts prevent using rainbow tables. A random combination of hashes with tweakable knobs, or whatever his suggestion is, is just a complicated way of salting except you have the possibility of weakening your function if you don't know what you are doing (as another has already mentioned, the unexpected behaviour of combining DES should be remembered).
It will not deter targeted attacks (spearfishing) by competent attackers, but again, not much would.