Bug 745555

Why do you think so?

BTW the support for bcrypt would have to be in glibc, so please direct your efforts to get bcrypt support for passwd to glibc upstream.

(In reply to comment #1)
> Why do you think so?

Because all of the existing mechanisms supported by Fedora/RHEL are really weak:
 http://codahale.com/how-to-safely-store-a-password/

> BTW the support for bcrypt would have to be in glibc, so please direct your
> efforts to get bcrypt support for passwd to glibc upstream.

Done:
 http://sourceware.org/bugzilla/show_bug.cgi?id=13286

Upstream replied, ref: http://sourceware.org/bugzilla/show_bug.cgi?id=13286#c6

"The implementation you are talking about is already exists (since 1998).
It's called crypt_blowfish, you can find more information about it at
http://www.openwall.com/crypt/
Some GNU/Linux distributions integrated crypt_blowfish to their glibc packages
long time ago, much before the moment of adding rival SHA-based algorithms to
mainline glibc (about 4 years ago).

AFAIK the decision to not consider including bcrypt support to mainline glibc
was a political one, so I very much doubt raising this issue in bugzilla could
affect that decision."

So Red Hat is a company to whom politics matter more than security? So we should all have insecure systems because Red Hat would rather play at politics that fix well known security problems?

This answer is patently ridiculous. 

Furthermore, most distributions put said support in a shared library, such that one can employ the additional functionality as desired. Why was this not employed?

This will be highlighted during our discussion with our sales rep for reasons why we won't be paying any more for Red Hat "support", if one can use the word that vaguely. Over the years we've learned that we're only paying for the privilege of being told what Red Hat can't be bothered to fix. We couldn't find a single bug we'd opened that has been fixed in numerous years of paid support.

I just can't let Jo's comment stand as the last comment here.
So for the record, I have to say that Jo was missing the point.

1.) This was a BZ for Fedora 16; not RHEL. If a paying Red Hat customer wants to leverage their support subscription, they need to open a support case.

2.) No one from Red Hat ever said this had anything to do with politics. That phrase came into it when an upstream glibc contributor (Dmitry V. Levin) commented on the referenced bz.

To be clear, the last time glibc looked at bcrypt() was when MD5 was the best that glibc's crypt() could do. 2007. That was when they implemented the currently-used SHA-2 based method. In the original announcement and accompanying spec paper, the glibc maintainer explained the decision clearly:

    > I can already hear everybody complaining that I suffer from the NIH syndrome but this is not the reason. The same people who object to MD5 make their decisions on what to use also based on NIST guidelines. And Blowfish is not on the lists of the NIST. Therefore bcrypt() does not solve the problem.

And also:

    > Security departments in companies are trying to phase out all uses of MD5.  They demand a method which is officially sanctioned. For US-based users this means tested by the NIST. This rules out the use of another already implemented method with limited spread: the use of the Blowfish encryption method. The choice comes down to tested encryption (3DES, AES) or hash sums (the SHA family).

Refer:

    - http://www.akkadia.org/drepper/sha-crypt.html and 
    - http://www.akkadia.org/drepper/SHA-crypt.txt

3. Saying that lack of bcrypt denotes "insecure systems" with "well known security problems" is to quote Jo, "patently ridiculous".

In short, the codahale article isn't all-bad, but it completely ignores the fact that virtually no implementation of SHA-2-based password-hashing (including glibc's crypt() in RHEL/Fedora) does only a single round. Just like bcrypt, we have a scheme with a configurable number of rounds.

All that said, I think it's time we address this a little more clearly, so may I present my attempt at explaining this whole situation:

    bcrypt support for passwords in /etc/shadow
    https://access.redhat.com/articles/1519843

As the current SHA-2 based password hash is fairly sufficient and comparable with bcrypt in regards to security for implementing any additional password hash we should wait for the Password Hashing Competition (https://password-hashing.net/candidates.html) to select the best choice. The support should be of course added to glibc and not to individual consumers of the crypt() function.