Often people say "Don't roll your own security" but the reality is that developers aren't trying to roll their own. They are trying to solve a problem, and if a quick google doesn't turn up a good library then they'll try and figure it out. Googling for password security implementations is likely to be fraught with horrible horrible advice.
I guess what I'm saying is that it's not enough to say don't do it, instead the defaults need to be there (and very visible).
I think we've reached a point with bcrypt that a good secure password system is within reach and comes with sane defaults and ease of use as features for most programming languages.
If it's just an issue of getting the word out there, then I'm hopeful things can improve.
You need more than just bcrypt. You've hinted at other things, but a few random things popping in to my mind:
* Preventing password logging (many web frameworks log parameters)
* Secure password recovery
* New alternative attack vectors (eg. Facebook, Twitter auth)
* XSS and CSRF
There are so, so many simple to make security errors, and worse - many of them are inter-related so that forgetting one will make another vulnerable. This is why you need safe defaults and more Security education.
A strong password hash doesn't gate on any of those things, so, while you do indeed need to pay attention to them, you don't need to pay attention to them before you deploy a strong password hash.
You should deploy a strong password hash immediately.
True point and this is probably off topic, but out of curiosity, what is the recommended approach for his point about logging messages/requests?
On previous projects, we've gone through all sorts of machinations to detect a password in our SOAP logging. This usually involves XML parsing (slow, ineffective on malformed messages) and Regexes (ineffective on malformed or "unusual" messages).
I can't think of anything better, short of "you can't leak what you don't log" which is nice in theory but not always practical.
There are defaults bcrypt and PBKDF2. There is no excuse for anyone to do anything less than salted hashes even if the decide not to follow bcrypt or PBKDF2.
I guess what I'm saying is that it's not enough to say don't do it, instead the defaults need to be there (and very visible).