Use SHA-2 by default instead of MD5 for password encrypting
bruce.dubbs at gmail.com
Tue Dec 28 22:25:47 PST 2010
William Immendorf wrote:
> Let's face it: MD5, while it might be more than plain old DES, it is a
> weak algorithm to encrypt your passwords with. To give you proof, in
> 2008, researchers demonstrated that MD5 is very weak to collision
> attacks, and can create false data that appears to be trustworthy. For
> And the recommendation: Do not use MD5 for anything. This includes
> certificates, passwords, and even for verifying files. So, this means
> that it's time to switch to different algorithms.
> The only two choices we have right now are Blowfish, and SHA-2 (256
> and 512). Since using Blowfish requires modifications to Glibc and
> Shadow, this means the easiest route to take would be to use SHA-2.
> What this means for both LFS and BLFS is:
> * The Shadow instructions need to have the password encryption
> changed from MD5 to SHA-512
> * The PAM configuration files also need MD5 converted to SHA-512
> * And all of the MD5 hashes for the packages need to be converted to
> SHA-256 hashes.
> The last one would require changes to all of the books in order to
> work. But belive me, with the flaws that MD5 has, you probably want to
> ditch it sooner or later.
> As for which list this belongs on, I belive it belongs on all of the
> -dev lists, but I'll first send it to the lfs-dev list.
You are probably right about shadow, but the main reason for the
checksums for package downloads is to provide data integrity, not
security. The better way for ensuring a package has not been
intentionally modified is to use digital signatures.
The chances that a package at one of the sites where we get packages is
quite small. Since we are downloading source code. The changes would
be detected fairly quickly and the fact that it happened would be all
over the net.
For shadow, I believe the only change needed is the third sed:
sed -i -e 's@#ENCRYPT_METHOD DES at ENCRYPT_METHOD SHA512@' \
-e 's@/var/spool/mail@/var/mail@' etc/login.defs
Although PAM is in BLFS, I'm not aware of any changes to that package
that would be needed to utilize a different login encryption method.
For changing a password, I think that PAM uses whatever method currently
is in use. Let me add a caveat though. I haven't used PAM in several
years. I think it just gets in the way.
I think this is the right list for the discussion.
More information about the lfs-dev