7 ms·

Overall, the article is solid. It is only missing key stretching with fast cryptographic hashing algorithms like SHA-1 or SHA-2. Instead, it jumps right into PB

Overall, the article is solid. It is only missing key stretching with fast cryptographic hashing algorithms like SHA-1 or SHA-2. Instead, it jumps right into PBKDF2 and bcrypt. That's fine, but it's not the full story, and as such, does a disservice for those wanting to know about securely storing passwords on disk. PBKDF2 and bcrypt can be a performance killer for authentication applications, if the host is a busy host. Instead, changing the number of rotations on a fast hashing algorithm gives you finer granularity on brute force speed versus application and host reliability.

eterm 12y ago
The whole point of bcrypt is to be slow. You can set the number of rounds to fine-tune that too, and can even do it on a user by user basis since the number of rounds and version is stored within the hash output.
- atoponce 12y ago
  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
  - 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
Many of the largest, busiest applications in the world authenticate passwords with bcrypt. Misplaced concern about its performance implications are as approximately as old as the algorithm itself. Hardware slices through iterations of fast hash functions --- functions that are designed to be quickly executed on hardware --- like a red-hot knife through warm butter. Developers who think they're getting "fine-grained control" over brute force speed by tinkering with SHA2 are deluding themselves. PBKDF2 is not simply the repeated application of SHA2. Don't use fast hashes for passwords. Don't design constructions that use fast hashes for passwords. That work has been done for you already: use scrypt, instead of an underspecified, half-functional, and insecure homebrew approximation of scrypt.
- atoponce 12y ago
  Software library support for bcrypt and scrypt is still light (although there is admittedly more support for the former than the latter). Which would could cause you to roll your own in-house solution. This is less optimal. There is ubiquitous library support for key stretching with fast hashes.
  - matthewmacleod 12y ago
    Really? I'm pretty sure that there's near-ubiquitous support for bcrypt for any language or framework, no?
  - tptacek 12y ago
    Name a single widespread environment for which no secure password hash is available.
    - atoponce 12y ago
      MySQL for bcrypt and/or scrypt.
      - tptacek 12y ago
        Plenty of applications built on MySQL use bcrypt. For example: see virtually every Rails app.
valarauca1 12y ago
Fast cryptographic hashes like SHA-1/2 are heavily discouraged for password storage (even with a salt). As they are very easy to implement in parallel. Yes salting prevents as effective brute forcing. Yet modern computing 8 char passwords + salt can be exhausted within 24-48 hours (on a <$20k GPU cluster) if you using SHA-1/2 + salt. bcrypt/scrypt/PBKDF2 are much harder to brute force (by design) and circumvent this weakness.
- tptacek 12y ago
  Tangent: Salts do zero to mitigate brute-force attacks. Salts defend against one idiosyncratic lookup-table attack that was briefly popular in the early 2000s because of a widely-deployed password hash function that, unlike every password hash since the mid-1970s, didn't randomize. This is the attack to which "rainbow tables" are applied. If you're considering rainbow tables as part of your threat model, you're already so boned that you should give up and just use a real password hash. If you're not considering rainbow tables, you don't have to consider salts. The only good thing about "strong salts" is that they function as a kind of shibboleth so you can tell if people understand what problems they're contending with when storing passwords.
  - frik 12y ago
    > "every password hash since the mid-1970s" Back then systems used no password at all or stored it in plain text. In the mid-1970s the NSA just finished DES. Password shadowing first appeared in UNIX systems with the development of System V Release 3.2 in 1988 - see: http://en.wikipedia.org/wiki/Passwd#History http://en.wikipedia.org/wiki/Passwd#History > "briefly popular in the early 2000s" Til the dot-com-bubble timeframe many websites stored plain text passwords in databases, later they shifted to SHA1/MD5 hashed passwords without salt. Only with the Sony hacks a few years ago, many added some kind of salting.
    - tptacek 12y ago
      The original Unix crypt function was, IIRC, salted. To head off an unproductive discussion, I'll just repeat: * salts do zero to mitigate brute-force attacks * even trivial salt schemes break table-based attacks * the overwhelming majority of passwords are cracked through brute-force, which is attack vector that real-world password hashes need to be evaluated on.
kerkeslager 12y ago
> It is only missing key stretching with fast cryptographic hashing algorithms like SHA-1 or SHA-2. Instead, it jumps right into PBKDF2 and bcrypt. Key stretching with SHA-1 or SHA-2 is hard to do right, and if you do it right, you've reached a solution that is basically equivalent to PBKDF2 or bcrypt. If you're interested in how PBKDF2 or bcrypt are implemented, that's one thing, but if you're rolling your own password stretching on top of SHA-1 or SHA-2, you're probably not doing it correctly and performing [security theater](http://en.wikipedia.org/wiki/Security_theater http://en.wikipedia.org/wiki/Security_theater). > PBKDF2 and bcrypt can be a performance killer for authentication applications, if the host is a busy host. Instead, changing the number of rotations on a fast hashing algorithm gives you finer granularity on brute force speed versus application and host reliability. This is already provided by PBKDF2 and bcrypt. Both can be configured to run more or fewer rounds.

eterm 12y ago

The whole point of bcrypt is to be slow. You can set the number of rounds to fine-tune that too, and can even do it on a user by user basis since the number of rounds and version is stored within the hash output.

atoponce 12y ago
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
- 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

Many of the largest, busiest applications in the world authenticate passwords with bcrypt. Misplaced concern about its performance implications are as approximately as old as the algorithm itself. Hardware slices through iterations of fast hash functions --- functions that are designed to be quickly executed on hardware --- like a red-hot knife through warm butter. Developers who think they're getting "fine-grained control" over brute force speed by tinkering with SHA2 are deluding themselves. PBKDF2 is not simply the repeated application of SHA2. Don't use fast hashes for passwords. Don't design constructions that use fast hashes for passwords. That work has been done for you already: use scrypt, instead of an underspecified, half-functional, and insecure homebrew approximation of scrypt.

atoponce 12y ago
Software library support for bcrypt and scrypt is still light (although there is admittedly more support for the former than the latter). Which would could cause you to roll your own in-house solution. This is less optimal. There is ubiquitous library support for key stretching with fast hashes.
- matthewmacleod 12y ago
  Really? I'm pretty sure that there's near-ubiquitous support for bcrypt for any language or framework, no?
- tptacek 12y ago
  Name a single widespread environment for which no secure password hash is available.
  - atoponce 12y ago
    MySQL for bcrypt and/or scrypt.
    - tptacek 12y ago
      Plenty of applications built on MySQL use bcrypt. For example: see virtually every Rails app.

valarauca1 12y ago

Fast cryptographic hashes like SHA-1/2 are heavily discouraged for password storage (even with a salt). As they are very easy to implement in parallel. Yes salting prevents as effective brute forcing. Yet modern computing 8 char passwords + salt can be exhausted within 24-48 hours (on a <$20k GPU cluster) if you using SHA-1/2 + salt. bcrypt/scrypt/PBKDF2 are much harder to brute force (by design) and circumvent this weakness.

tptacek 12y ago
Tangent: Salts do zero to mitigate brute-force attacks. Salts defend against one idiosyncratic lookup-table attack that was briefly popular in the early 2000s because of a widely-deployed password hash function that, unlike every password hash since the mid-1970s, didn't randomize. This is the attack to which "rainbow tables" are applied. If you're considering rainbow tables as part of your threat model, you're already so boned that you should give up and just use a real password hash. If you're not considering rainbow tables, you don't have to consider salts. The only good thing about "strong salts" is that they function as a kind of shibboleth so you can tell if people understand what problems they're contending with when storing passwords.
- frik 12y ago
  > "every password hash since the mid-1970s" Back then systems used no password at all or stored it in plain text. In the mid-1970s the NSA just finished DES. Password shadowing first appeared in UNIX systems with the development of System V Release 3.2 in 1988 - see: http://en.wikipedia.org/wiki/Passwd#History http://en.wikipedia.org/wiki/Passwd#History > "briefly popular in the early 2000s" Til the dot-com-bubble timeframe many websites stored plain text passwords in databases, later they shifted to SHA1/MD5 hashed passwords without salt. Only with the Sony hacks a few years ago, many added some kind of salting.
  - tptacek 12y ago
    The original Unix crypt function was, IIRC, salted. To head off an unproductive discussion, I'll just repeat: * salts do zero to mitigate brute-force attacks * even trivial salt schemes break table-based attacks * the overwhelming majority of passwords are cracked through brute-force, which is attack vector that real-world password hashes need to be evaluated on.

kerkeslager 12y ago

> It is only missing key stretching with fast cryptographic hashing algorithms like SHA-1 or SHA-2. Instead, it jumps right into PBKDF2 and bcrypt. Key stretching with SHA-1 or SHA-2 is hard to do right, and if you do it right, you've reached a solution that is basically equivalent to PBKDF2 or bcrypt. If you're interested in how PBKDF2 or bcrypt are implemented, that's one thing, but if you're rolling your own password stretching on top of SHA-1 or SHA-2, you're probably not doing it correctly and performing [security theater](http://en.wikipedia.org/wiki/Security_theater http://en.wikipedia.org/wiki/Security_theater). > PBKDF2 and bcrypt can be a performance killer for authentication applications, if the host is a busy host. Instead, changing the number of rotations on a fast hashing algorithm gives you finer granularity on brute force speed versus application and host reliability. This is already provided by PBKDF2 and bcrypt. Both can be configured to run more or fewer rounds.