Bug 173002

Additional information can be found in this paper:
http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf

Particularly noticable is the below benchmark table, running "John the ripper"
on a P4 2.4GHz with 512M of RAM. Slower is better!
---------------------------------------------------
| Unix crypt ()            | 249467 hashes/second |
| BSDI DES (x725)          |   9618 hashes/second |
| FreeBSD MD5              |   4452 hashes/second |
| OpenBSD Blowfish         |    335 hashes/second |
| Kerberos AFS DES (short) | 244907 hashes/second |
| Kerberos AFS DES (long)  | 435745 hashes/second |
| Windows NT LanMan DES    | 628234 hashes/second |
---------------------------------------------------

Additional information can be found in this paper:
http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf

Particularly noticeable is the below benchmark table, running "John the ripper"
on a P4 2.4GHz with 512M of RAM. Slower is better!
---------------------------------------------------
| Unix crypt ()            | 249467 hashes/second |
| BSDI DES (x725)          |   9618 hashes/second |
| FreeBSD MD5              |   4452 hashes/second |
| OpenBSD Blowfish         |    335 hashes/second |
| Kerberos AFS DES (short) | 244907 hashes/second |
| Kerberos AFS DES (long)  | 435745 hashes/second |
| Windows NT LanMan DES    | 628234 hashes/second |
---------------------------------------------------

Sounds like a very interesting for Fedora Core (maybe for FC5 already), too.

I'm not sure which packages would have to be modified for this to work
throughout the distribution well. Here is result of my investigation however it
may be incomplete:

PAM (pam_unix) - surely
shadow-utils - probably chpasswd only
passwd - is pamified however some changes are needed too
libuser - now supports only crypt() passwords in setpass

And this is definitely not something which should be implemented in RHEL4.

glibc - crypt() should support the format to keep the traditional way of checking
        passwords working

How could crypt() support the bcrypt format in a backwards compatible way? It
seems impossible to me as there is no way how to specify for example the cost
parameter. Also note that the already supported MD5 passwords don't have glibc
implementation but I agree that there should be a library implementation of the
bcrypt algorithm so the utilities can share it.

glibc crypt() does support md5, and it can support bluefish the same way,
by recognizing a salt prefix:
-------------------------------------
#include <crypt.h>
#include <stdio.h>
#include <stdlib.h>

int
main (int _, char *argv[])
{
        printf ("%s\n", crypt (argv[1], argv[2]));
        return EXIT_SUCCESS;
}
-------------------------------------
$ ./a.out foo '$1$abcdefgh$'
$1$abcdefgh$XxzGe9Muun7wTYbZO4sdr0

Ah, OK.

Eric, can you file separate bugs against glibc, shadow-utils, passwd and libuser
and make them blocking this bug?

OK, done

glibc: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173834
shadow-utils: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173849
passwd: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173851
libuser: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173853

How about the authconfig and authconfig-gtk which we might want to upgrade for
support of a new option in /etc/sysconfig/authconfig maybe in the form of
USEBLOWFISH=yes

Also does pam need work? Should I open yet another bug there?

Please file a bug against authconfig as well.

No need for another PAM bug - I'll track it here.

Done, I have also opened bugs for anaconda and kickstart support.

authconfig: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173863
anaconda, interactive installation:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173864
anaconda, kickstart support:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173866
system-config-kickstart: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173867

Debian, Suse, and Gentoo all do this with libxcrypt, as a dropin 
replacement for glibc's libcrypt.

The newest source I could find for libxcrypt was here:
http://packages.qa.debian.org/libx/libxcrypt.html

(In reply to comment #12)
> Debian, Suse, and Gentoo all do this with libxcrypt, as a dropin 
> replacement for glibc's libcrypt.
> 
> The newest source I could find for libxcrypt was here:
> http://packages.qa.debian.org/libx/libxcrypt.html
> 
> 
> 

Tried it here with FC6 ( compiled libxcrypt and pam_unix2 manually ) and the
system works without problems.

Still no support in authconfig, anaconda and kickstart for configuration ...

I second the need for blowfish encryption for local passwords.

Blowfish will not be supported since it does not solve the issue (see
http://people.redhat.com/drepper/sha-crypt.html).  But glibc will have a new
password hashing method based on SHA.

All the tools will need to be updated now.  Note that when creating a salt
string there are now parameters to consider.  Talk to me when you start
implementing the extensions.

(In reply to comment #12)
>Debian, Suse, and Gentoo all do this with libxcrypt, as a dropin 
>replacement for glibc's libcrypt.

SUSE uses the regular Glibc libcrypt for Blowfish.

Generally: Other than glibc, nothing that already uses glibc has to be patched -
this is especially a relief wrt. pam_unix2 (why does fedora still use pam_unix?)
and the openldap server.

Regular glibc doesn't support Blowfish. Perhaps SUSE patches it in?
But it now supports sha256 and sha512 and current pam in rawhide contains option
to prefer it for new passwords. So I consider this bug - in the sense of having
available a harder-breakable algorithm available - fixed.

(In reply to comment #17)
> So I consider this bug - in the sense of having
> available a harder-breakable algorithm available - fixed.

I'm sorry -- I disagree. The request was for Blowfish specifically. While having SHA support is certainly a good thing for those organizations that wish to use it, implementing SHA does not negate the validity of the use case for Blowfish.

An organization choosing to implement Blowfish may do so in order that hashes are consistent across disparate systems. This allows the practice of distributing shadow files, for example. Similarly, the point that NIS[+]/LDAP/krb is "better" may be correct, but is also irrelevant. The choice to distribute shadows is a valid business practice, and Blowfish is not an unreasonable choice for the hash.

FWIW, this issue is sufficiently important that it is among the reasons, and indeed may be the tipping point reason, I am considering migrating my compute clusters from RHEL to SLES. We are primarily a SUSE shop, but have adopted RHEL for our compute clusters. I am okay with the operations cost of maintaining this split personality shop, as our cluster vendor [Platform] has been good at supporting us with RHEL. I would, however, like to standardize our password hash (and, as CIO, such foolish things as "standards" and "business practices" are my prerogative). Changing our hash algorithm (e.g. to SHA) and implementing it across all systems and accounts is too costly to consider. [If it had been MD5, I would have taken on the pain of migrating to something else everywhere, and then I probably would have chosen SHA. But I am content with Blowfish, and it is already what I have across many systems.]

If you're really interested, yes I am in the process of migrating to a central authentication system (Centrify). My point is that this request is valid as originally requested. In particular, the choice of password hash should be a matter of business practice, and there is broad community support for Blowfish as one of the options.

I don't say that request for explicitly supporting blowfish is invalid. We just did not decide to implement it and implemented methods that can be FIPS validated. If you want us to reconsider this issue please use regular support channels (http://www.redhat.com/support) to open a case for this RFE.

I don't see any problem using SUSE :)

This bug is closed because implementing it didn't solve a problem with a different, much weaker protocol?

I beg to differ. Bcrypt solves every problem with SHA by removing its weak self entirely.

Also, there is need for password synchronization across numerous infrastructures which any change to SHA did not solve.

This issue 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.