Users

Download

users@exim4u.org

August 2014

1 participants
1 discussions

Fix suggestion for broken login on Linux Distributions with suhosin patched PHP (e.G. Debian Wheezy)
by Seidel, Michael 05 Aug '14

05 Aug '14

Hi List, I ran into a problem lately and I thought it was best to report my findings. I was upgrading a system Debian Lenny to Wheezy (yeah, I know, it took some time, but it was for internal use anyway) and therefor from vexim to exim4u. So far so good, but after changing the password from CHANGE to something else failed my login. A quick look in the database revealed the issue: The password encryption scheme changed from md5 to sha512, as you can easily see on the encrypted passwords itself: Old: CHANGE : $1$12345678$2lQK5REWxaFyGz.p/dos3/ New: CHANGE : $6$P0s1h8hgqT/K$qGoe/zSh6crG/MsDTlnxmnGGufEVftsB2sPCgfopV6TmoT2XBVgGQ6cAu00GJUY9GHaTO1RsNDJUNwY1MZqQa/ See http://php.net/manual/en/function.crypt.php for those without crypto basic knowledge with additional information on this. The old one was plain MD5 (starting with $1$SALT$...), which you should not use anymore, but better than plain, right guys? ;-))) A real patch for this incoming? I'll be looking at http://axel.sjostedt.no/misc/dev/vexim-customizations/ next. The new one is SHA-512 (Starting with $6$SALT$...), which is way longer (so it needed the - already implemented - var(255) mysql patch mentioned on this list before) and it has a 16 character salt. But login was broken at that point. I found out, that a suhosin patch was added to Debian PHP - to promote more secure passwords, but it broke some older scripts. After some fiddling with the function crypt_password code in ./config/functions.php I'd suggest a code change to: --------------------------- function crypt_password($clear, $salt = '') { global $cryptscheme; if ($cryptscheme == 'sha') { $hash = sha1($clear); $cryptedpass = '{SHA}' . base64_encode(pack('H*', $hash)); } else { if ($salt != '') { if ($cryptscheme == 'sha512') { $salt = substr($salt, 0, 16); } else if ($cryptscheme == 'des') { $salt = substr($salt, 0, 2); } else if ($cryptscheme == 'md5') { $salt = substr($salt, 0, 12); } else { $salt = ''; } $cryptedpass = crypt($clear, $salt); } else { $cryptedpass = crypt($clear); } } return $cryptedpass; } --------------------------- So if somebody ran into that problem again they just have to set /* Set to either "sha", "sha512", "des" or "md5" depending on your crypt() libraries */ $cryptscheme = "sha512"; in ./config/variables.php --------------------------- Some real class to check which encoding to use would be more cool but not necessary IMHO. You need to configure your backend with certain encoding anyways, just think about IMAP/POP services which require a set crypt scheme. BUG: My code piece will result in first login failures if somebody just did not login first to have the password converted from md5 to sha-512 to find out their system changed their encoding but already changed the var in variables.php to sha512. They eventually come here to read about this: So please change it back to default: md5 , login and than change it back to sha512 or copy that sha512 crypt password from above to database. So what does the List say about this? Is this the correct solution? Regards, Michael Seidel System Administrator FAI rent-a-jet AG http://www.fai.ag

1 0