enforce blowfish encryption for RHEL5

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
In my /etc/system-auth file I have
the line:

password   sufficient   pam_unix.so md5 shadow ....

I want to use blowfish instead of MD5 encryption.
I tried changing "md5" to "blf" and "blowfish" but the /etc/shadow
file does not give the usual "$2$" prefix in password fields.

What is the right abbreviation to use for this entry to get blowfish
work for passwords in RHEL5?  Do I need another package?

Thanks in advance.

Re: enforce blowfish encryption for RHEL5

On 11/26/2008 01:13 PM, The Derfer sent:
Quoted text here. Click to load it

I wonder if you meant to type that the file is located in:

   /etc/pam.d/system-auth   instead?

Without burrowing much deeper, it appears as if the current choices are
md5 or /not/ md5.  Some Googling suggests sha256, sha512 and blowfish is
possible with other PAM versions.  You know our Tikanga is not an early

Despite what's been published, md5 will be a safe choice for a long
time.  And yes perhaps it should be on our todo list.  If you hang
around the sci.crypt newsgroup for awhile, you'd find that md5
collisions were quite a discovery, but they believe md5 is still safe
for now.


@?6A62?FEH9:DE=6o2@=]4@> [r4o7t]

Re: enforce blowfish encryption for RHEL5

1PW wrote:
Quoted text here. Click to load it

The current patch level of RHEL5 supports SHA-256 (sha256 keyword) and
SHA-512 (sha512 keyword) as arguments of pam_unix.so.  MD5 in the shadow
file itself is supported for passwords that haven't been changed since
the new keywords went into effect.  I've never made any manual changes
to the arguments of pam_unix.so, and the current setting in my
system-auth file is sha512.

MD5 is acceptable as a cryptographic hash only if it's well-implemented,
which UNIX passwords are.  Acceptability really just means people
shouldn't panic if their current technology involves properly
implemented MD5.  You should really migrate to one of the SHA variants
as soon as possible.  (Improperly implemented cryptography is never
recommended, no matter how strong the improperly implemented algorithms

Site Timeline