Bug 173002 - Blowfish for passwd/shadow encryption
Blowfish for passwd/shadow encryption
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Jay Turner
: FutureFeature
Depends On: 173834 173849 173851 173853
Blocks: 173863 173864 173866
  Show dependency treegraph
 
Reported: 2005-11-11 18:40 EST by Eric Moret
Modified: 2015-01-07 19:11 EST (History)
14 users (show)

See Also:
Fixed In Version: pam-0.99.8.1-14
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 17:59:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Moret 2005-11-11 18:40:18 EST
Description of problem:

In addition to standard md5, I would like to have the option of using blowfish
hash in passwd/shadow files. This features originates from OpenBSD
(http://www.openbsd.org/papers/bcrypt-paper.pdf) and has been shipping on OWL
since 2002 (http://www.openwall.com/crypt/) and Suse for several years now. Not
sure where to assign this feature request: pam ? passwd? glibc? authconfig?

Version-Release number of selected component (if applicable):

pam-0.77-66.13
passwd-0.68-10.1
glibc-2.3.4-2.13
authconfig-4.6.10-rhel4.1

How reproducible:
Always

Steps to Reproduce:

Not sure how to enable the feature if available. Doc does not talk about it.
Might need to apply patch indicated in (description of problem) above.
  
Actual results:


Expected results:


Additional info:
Reference to an old discussion on Redhat's pam-list archive
https://www.redhat.com/archives/pam-list/2003-September/msg00061.html
Comment 1 Eric Moret 2005-11-11 20:28:55 EST
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 |
---------------------------------------------------
Comment 2 Eric Moret 2005-11-11 20:29:53 EST
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 |
---------------------------------------------------
Comment 3 Robert Scheck 2005-11-12 07:18:59 EST
Sounds like a very interesting for Fedora Core (maybe for FC5 already), too.
Comment 4 Tomas Mraz 2005-11-16 12:54:14 EST
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.
Comment 5 Miloslav Trmač 2005-11-16 13:05:42 EST
glibc - crypt() should support the format to keep the traditional way of checking
        passwords working
Comment 6 Tomas Mraz 2005-11-16 16:12:17 EST
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.
Comment 7 Miloslav Trmač 2005-11-17 10:05:00 EST
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
Comment 8 Tomas Mraz 2005-11-21 04:29:45 EST
Ah, OK.

Eric, can you file separate bugs against glibc, shadow-utils, passwd and libuser
and make them blocking this bug?
Comment 9 Eric Moret 2005-11-21 16:29:20 EST
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?
Comment 10 Tomas Mraz 2005-11-21 16:45:52 EST
Please file a bug against authconfig as well.

No need for another PAM bug - I'll track it here.
Comment 11 Eric Moret 2005-11-21 19:04:44 EST
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
Comment 12 Eric Jarman 2006-01-10 11:45:01 EST
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


Comment 13 Tyler 2006-11-16 08:30:48 EST
(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 ...
Comment 14 Thomas M Steenholdt 2006-12-04 04:46:35 EST
I second the need for blowfish encryption for local passwords.
Comment 15 Ulrich Drepper 2007-09-19 18:43:46 EDT
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.
Comment 16 Jan Engelhardt 2007-12-26 15:52:22 EST
(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.
Comment 17 Tomas Mraz 2008-01-09 17:59:36 EST
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.
Comment 18 Clark Gaylord 2012-06-01 04:35:08 EDT
(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.
Comment 19 Tomas Mraz 2012-06-01 05:07:58 EDT
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.
Comment 20 Jan Engelhardt 2012-06-01 05:24:36 EDT
I don't see any problem using SUSE :)
Comment 21 Jo Rhett 2014-12-19 15:51:21 EST
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.

Note You need to log in before you can comment on or make changes to this bug.