3 ms·

Of course bcrypt is supposed to be slow. However, the "fastest" bcrypt can operate, might be a local DDoS for your sever, if the authentication app is a busy on

Of course bcrypt is supposed to be slow. However, the "fastest" bcrypt can operate, might be a local DDoS for your sever, if the authentication app is a busy one. Key stretching cryptographic hashing algorithms gives you more granular control in that regard.

tptacek 12y ago
So does every database lookup every application does. The solution to that problem is rate limiting, not (weird that I have to say this) weakening your password authenticators!
- atoponce 12y ago
  Security margins here (IE: bcrypt versus SHA-2) are estimated with entropy, which is also completely missing in the article. A weak password is a weak password, bcrypt or not. If there is sufficient entropy behind the password, 500,000 rotations of SHA-512 is not "weaker" than bcrypt, Only faster. You should know this (weird that I had to say that).
  - ghshephard 12y ago
    Speeding up your password hash mechanism makes it weaker. The faster your password hash system, the more quickly your password list can be broken. This is probably the best commentary I've seen on the topic of how many rounds you should incorporate into your KDF (Scrypt/Bcrypt/PBKDF2 all let you dial as many as you wish), so I won't try and improve on it: http://security.stackexchange.com/a/3993 http://security.stackexchange.com/a/3993
    - atoponce 12y ago
      You're overlooking the entropy behind the hash though. If entropy is sufficient for creating the password (120-bits or so), no matter of brute force speed will recover the text that created the hash. You'll instead need to break the hashing algorithm itself. The math is against you.
      - deleted 12y ago
        [deleted]
      - ghshephard 12y ago
        If you have 120 bits of entropy, then a single round of unsalted SHA-2 is sufficient. If you have typical users, with typical user passwords, then take a few minutes to read through: http://security.stackexchange.com/a/3993 http://security.stackexchange.com/a/3993 (it discusses the importance of taking into account entropy) to determine what work factor is appropriate for your situation, then just deploy one of scrypt/bcrypt/PBKDF2 with that work factor.
        tptacek 12y ago
        Yes. The basic job of a password hash is to improve the security of low-entropy secrets. The argument here seems to be that if people simply don't use passwords, but instead secure AES keys, password hashes won't matter. Ok, but we're talking about passwords, and so was he, upthread.
  - copsarebastards 12y ago
    > If there is sufficient entropy behind the password, 500,000 rotations of SHA-512 is not "weaker" than bcrypt, Only faster. Given that the strength of security is measured in how long it takes to break it, and hash time is directly correlated with brute force time, for the same password, faster is weaker. Having high-entropy passwords certainly increases security, but it's a well-known fact that users don't use high-entropy passwords, so that's pointless to talk about.
amckenna 12y ago
If you server cannot hash incoming authentication attempts properly with bcrypt or scrypt, then the solution is to upgrade the server, not weaken your authentication to compensate.
- atoponce 12y ago
  Are you offering to upgrade my hardware infrastructure for me?
  - amckenna 12y ago
    I assess the vulnerability of applications for a living and I have been told over and over again by dev groups and ops that they can't upgrade their systems because it is too expensive. That's fine, but you need to understand you are making a security for money tradeoff and realize the risks you are bringing on in doing so. Make your own cost benefit analysis, but know that you are making a tradeoff and what that entails. This is a solved problem: use 10,000+ rounds of PBKDF2, 4-5+ rounds of Bcrypt, or a sufficient work factor for Scrypt.
    - atoponce 12y ago
      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

So does every database lookup every application does. The solution to that problem is rate limiting, not (weird that I have to say this) weakening your password authenticators!

atoponce 12y ago
Security margins here (IE: bcrypt versus SHA-2) are estimated with entropy, which is also completely missing in the article. A weak password is a weak password, bcrypt or not. If there is sufficient entropy behind the password, 500,000 rotations of SHA-512 is not "weaker" than bcrypt, Only faster. You should know this (weird that I had to say that).
- ghshephard 12y ago
  Speeding up your password hash mechanism makes it weaker. The faster your password hash system, the more quickly your password list can be broken. This is probably the best commentary I've seen on the topic of how many rounds you should incorporate into your KDF (Scrypt/Bcrypt/PBKDF2 all let you dial as many as you wish), so I won't try and improve on it: http://security.stackexchange.com/a/3993 http://security.stackexchange.com/a/3993
  - atoponce 12y ago
    You're overlooking the entropy behind the hash though. If entropy is sufficient for creating the password (120-bits or so), no matter of brute force speed will recover the text that created the hash. You'll instead need to break the hashing algorithm itself. The math is against you.
    - deleted 12y ago
      [deleted]
    - ghshephard 12y ago
      If you have 120 bits of entropy, then a single round of unsalted SHA-2 is sufficient. If you have typical users, with typical user passwords, then take a few minutes to read through: http://security.stackexchange.com/a/3993 http://security.stackexchange.com/a/3993 (it discusses the importance of taking into account entropy) to determine what work factor is appropriate for your situation, then just deploy one of scrypt/bcrypt/PBKDF2 with that work factor.
      - tptacek 12y ago
        Yes. The basic job of a password hash is to improve the security of low-entropy secrets. The argument here seems to be that if people simply don't use passwords, but instead secure AES keys, password hashes won't matter. Ok, but we're talking about passwords, and so was he, upthread.
- copsarebastards 12y ago
  > If there is sufficient entropy behind the password, 500,000 rotations of SHA-512 is not "weaker" than bcrypt, Only faster. Given that the strength of security is measured in how long it takes to break it, and hash time is directly correlated with brute force time, for the same password, faster is weaker. Having high-entropy passwords certainly increases security, but it's a well-known fact that users don't use high-entropy passwords, so that's pointless to talk about.

amckenna 12y ago

If you server cannot hash incoming authentication attempts properly with bcrypt or scrypt, then the solution is to upgrade the server, not weaken your authentication to compensate.

atoponce 12y ago
Are you offering to upgrade my hardware infrastructure for me?
- amckenna 12y ago
  I assess the vulnerability of applications for a living and I have been told over and over again by dev groups and ops that they can't upgrade their systems because it is too expensive. That's fine, but you need to understand you are making a security for money tradeoff and realize the risks you are bringing on in doing so. Make your own cost benefit analysis, but know that you are making a tradeoff and what that entails. This is a solved problem: use 10,000+ rounds of PBKDF2, 4-5+ rounds of Bcrypt, or a sufficient work factor for Scrypt.
  - atoponce 12y ago
    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.