You're right. Throwing shit at the wall can screw things up, and you must still be using a proper full-strength hash, and not just throw crypto primitives at it.

What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach.

What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump.

So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'.

And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem.

That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production.

So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.