(1) Not only are rainbow tables avoidable, but they've been trivially avoidable since Unix crypt(3) was invented in the '70s. The only way you can become susceptable to them is if you make the mistake of designing your own scheme. So don't do that.
(2) There's a reason that no mainstream consumer application actually does this: as soon as you lock a normal user out of their account for an hour, you probably lose the user forever. Ok, there are two reasons: this technique doesn't add any security. Anybody nuts enough to brute-force your login page has as many IPs as they want. But that's not how they do it.
(3) People get to access password hashes as soon as you mess up a single database query. The idea behind storing safe hashes is to prevent your stupid mistakes from screwing over every one of your users. The stupidest people of all are the ones who assume they aren't going to make stupid mistakes.
You are right. Use whatever auth system which is available.
I think it's fine if you block IPs after they've hit a fail threshold for logins. Or at least freeze the account for a certain period of time (see failed iPhone login attempts).
I agree with you. People talk about this stupid hashing thing far, far too much. Especially because there's already a "right answer". Just use whichever auth plugin is most popular and provides bcrypt.
Can we talk about the real world, now? The reason Microsoft is driving modern offensive computing researchers nuts isn't that they got rid of the "stupid errors"; it's that they figured out how to make the runtime mitigate those errors with ASLR, NX, safe exceptions, and checked heaps.
In the real world --- and I am speaking from bitter and recent experience with very, very, very smart clients here --- you should assume you are going to make stupid mistakes, and do everything you can reasonably do to keep those mistakes from totally screwing over your customers.
I don't know, it seems to work pretty well for Microsoft
