I work for a local ISP that does shared web, email, and database hosting, among other things. I am one of the core system administrators. I am deeply familiar with hardware performance as it relates to software libraries, authentication, and busy systems. Feel free to wave a hand, ignoring the issue. But the fact remains that bcrypt can be a performance killer on busy systems.
No, it isn't, not on competently designed systems. But I freely concede that incompetence can make intractable problems out of all sorts of basic challenges.
It is a mystery to me how you would design a web application that required bcrypt on every page reference. For session-based browser apps, you use a cookie (properly secured) to note the session.
For applications requiring basic auth, you could cache the username/password combination after the first login.
For bcrypt to be a killer on modern systems, you are botching something in your authentication system.
I am not ignoring the issue, I am advocating the more secure system configuration. I know that it is expensive, and it can introduce additional performance requirements. When choosing to implement proper password hashing or not there is a tradeoff. That is a decision that needs to be made on a case by case basis.
None of that changes the fact that the _more secure_ thing to do is implement bcrypt/scrpt/PBKDF2. I bet there are plenty of people at Sony, Target, Adobe, Home Depot, Staples, etc. that wished they had taken the more secure route and spent that extra money.
