2 ms·

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 w

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.

amckenna 12y ago
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.
tptacek 12y ago
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.
- atoponce 12y ago
  So lack of deep financial pockets means incompetently designed systems? If a busy system can't handle bcrypt, it's incompetently designed?
  - tptacek 12y ago
    No. Yes.
  - par0xyzm 12y ago
    Bcrypt is adjustable, you can set the cost from 4 to 32. Most implementations provide a sane default of 10. If your system can't handle a bcrypt with a cost of 4, it is incompetently designed.
wglb 12y ago
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.

amckenna 12y ago

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.

tptacek 12y ago

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.

atoponce 12y ago
So lack of deep financial pockets means incompetently designed systems? If a busy system can't handle bcrypt, it's incompetently designed?
- tptacek 12y ago
  No. Yes.
- par0xyzm 12y ago
  Bcrypt is adjustable, you can set the cost from 4 to 32. Most implementations provide a sane default of 10. If your system can't handle a bcrypt with a cost of 4, it is incompetently designed.

wglb 12y ago

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.