3 ms·

> depending on work factor Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per th

• jfindley 10y ago
  The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU unfriendly due to memory allocation patterns) won't allow you to do much more than a dictionary / rule + dictionary attack, so in the short term you're only going to get weak passwords.
  • cm2187 10y ago
    I don't think anyone has any expectation that a login should be as fast as any other page load. Same thing for authorising a payment. I don't think a 1 sec delay when authenticating is unreasonable. To me the risk with using bcrypt is DOS. If you have a high work factor, all an attacker has to do is to run a lot of logon (no need to be successful, they just need to relate to real users) to sink your servers.
    • giovannibajo1 10y ago
      No matter what you do, you always need to have a rate limiter / DOS mitigation for your login APIs / pages.
  • seanwilson 10y ago
    > The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Is there a way client side processing power could be leveraged to help calculate the final hash value so that the computational cost could be practically increased? I'm aware that having the client calculate and send the final hash value by themselves is a bad idea though.