What is the specific reason to prefer bcrypt or PBKDF2 over SHA256-crypt in password hashes?
We know that to slow down password cracking in case a password database leak, passwords should be saved only in a hashed format. And not only that, but hashed with a strong and slow function with a possibility to vary the number of rounds.
But what about the SHA256 and SHA512 based hashes implemented in at least glibc (description, specification) and used by default at least on some Linux distributions for regular login accounts? Is there some reason not to use them, or to otherwise prefer bcrypt over the SHA-2 based hashes?
Of course bcrypt is significantly older (1999) and thus more established, but the SHA-2 hashes are already nine years old by now (2007), and scrypt is even younger by a bit (2009), but still seems to be mentioned more often. Is it just an accepted practice, or is there some other reason? Are there any known weaknesses in the SHA-2 based hashes, or has anyone looked?
Note: I specifically mean the multi-round password hashes described by the linked documents and marked with the codes
crypthashes, not a single round of the plain SHA256 or SHA512 hash functions.
I have seen the question this is marked as a possible duplicate of. The answers there have no mention of the SHA256-crypt / SHA512-crypt hashes, which is what I am looking for.
The "weakness" in hashes that don't have significant number rounds and aren't memory intensive are their speed or ease of implementation in a GPU/specialized hardware. Did you read the answers that you linked? They're better then any answer I could give you.
@Oasiscircle, well, the specification I linked to states "The default number of rounds for both algorithms is 5,000." and "maximum for N = 999,999,999". If that is not significant enough compared to bcrypt, I'd be happy to see that as an answer.
SHA functions are not memory intensive like Blowfish (which is what bcrypt is built with) and thus can more easily be parallelized in a GPU/specialized hardware. That's the reason why having more rounds with SHA is far less significant than more rounds of bcrypt. Side note, I cannot view your specification document from where I am currently.
@ilkkachu No, iterated hashing is not good enough. Attackers can run SHA in parallel on a GPU and get significant speedup. SHA is also used in bitcoin mining so there are plenty of ASICs that can bruteforce it.
@Navin, and still PBKDF2, which is likely built on SHA1 or SHA2 family, is usually listed as the first in the list of good password hashing functions, as in here, so again, the question is, what is the difference here?
@ilkkachu PBKDF2 can be used with any keyed HMAC. You can build a keyed HMAC with SHA, but you should not do that in new software!
@Navin, interesting note about SHA being used for bitcoin mining, but as far as I know, most ASICs are built to perform `sha256(sha256(x))`, so a Bitcoin mining ASIC may not be too helpful. It could be helpful if multiple iterations are used. (I.e., if number of iterations is even, perform all iterations on ASIC. Else, perform floor(iterationCount/2) iterations on ASIC and one iteration on GPU/CPU.) However, this ASIC advantage is defeated if the hashing scheme is something like `sha256(sha256(x)+Salt)`, because a mining ASIC cannot add data to the digest between first and second calculations.
The main reason to use a specific password hashing function is to make life harder for attackers, or, more accurately, to prevent them from making their own life easier (when compared to that of the defender). In particular, the attacker may want to compute more hashes per second (i.e. try more passwords per second) with a given budget by using a GPU.
SHA-256, in particular, benefits a lot from being implemented on a GPU. Thus, if you use SHA-256-crypt, attackers will be more at an advantage than if you use bcrypt, which is hard to implement efficiently in a GPU.
See this answer for some discussion of bcrypt vs PBKDF2. Though SHA-256-crypt is not PBKDF2, it is similar enough in its performance behaviour on GPU, so the same conclusions apply.
Case for SHA-512 is a bit less clear because existing GPU are much better at using 32-bit integers than 64-bit, and SHA-512 uses mostly 64-bit operations. It is still expected that modern GPU allow more hashes per second than CPU (for a given budget) with SHA-512-crypt, which again points at bcrypt as the better choice.
"Though SHA-256-crypt is not PBKDF2, it is similar enough in its performance behaviour on GPU, so the same conclusions apply." -- this is precisely what I was looking for.
For brute-force attacks, this can be compensated by adding just one character to the password. And supercompensated by two characters already.