From PBKDF2 vs Bcrypt, which is better?
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.
Often algorithms like PBKDF2, bcrypt and scrypt are recommended for this, with bcrypt seemingly getting the loudest votes, e.g. here, here and here.
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?
The SHA-2 family of hashes was designed to be fast. BCrypt was designed to be slow. From PBKDF2 vs Bcrypt, both are considered robust. With enough rounds or work-factor, either one can take longer than the other, but I would lean towards the one that was designed to be slow. (if server load is an issue, the Work Factor is adjustable)
Additionally, I would lean towards BCrypt because it is usually a Compiled implementation (C or C++).
The multi-round SHA can easily be implemented in high-level language, at least for the iteration, if not also for the hash itself. High level languages are less efficient for basic mathematical operations, reducing the number of rounds your production hardware can complete per millisecond.
While both algorithms can be implemented in either high- or low-level languages, or a hybrid; in BCrypt the options available dictate that you are more likely to land on an efficient implementation. (puts you on a more even playing field with the attacker)
In regards to your specific example from the /etc/shadow file, you are likely on only low-level (efficient) algorithms either way. (SHA or BCrypt) In this example I would suggest you consult the OS documentation to optimise the rounds (work factor) based on the speed of the hardware -vs- how strong you would like the hash to be.
scrypt (with a great enough work factor) has the added benefit of having extra RAM/Memory requirements (not just CPU), making it more GPU-resistant than SHA, BCrypt or PBKDF2.