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).

Some information on how bcrypt, scrypt and friends apply salting and stretching to resist attacks was in yesterday's post at http://throwingfire.com/storing-passwords-securely/ . It's worth a read.

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.

Thank you for clarifying!

You don't know what you're talking about.

Please elaborate for those of us who are not experts on cryptography.

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).