Dear All, after a bit (well, several hours...) of investigation, I found that:
1) md5 works flawlessly on my installation, while crypt does not. So it's not a configuration problem. 2) The code pre-1.3.5a, i.e. the one attached to bug report #703 (http://www.sogo.nu/bugs/view.php?id=703) worked fine (I've been using it on 1.3.4 without any problems). 3) In 1.3.5 the crypt() code was modularized and moved to NSstring+Utilities.m: > 2010-12-29 Ludovic Marcotte <[email protected]> > > * Moved the string encryption code from SoObjects/SOGo/SQLSource.m > to SoObjects/SOGo/NSString+Utilites.m 4) Feel free to correct me if I'm wrong, but it seems to me that the new implementation doesn't use the right salt. To perform a check against an existing md5-crypted password, you must fetch it from the DB and pass it as the second parameter to the crypt() function (the first will be the user-provided password to validate). This is because the salt to use is embedded into the crypted password (if you're using md5-crypt, it's the substring that starts with "$1$" and ends with "$"). The crypt() function will recognize the salt part automagically and use it to encode the user provided password. If you look at the patch code, you'll see the following lines: > buf = (char *) crypt([plainPassword UTF8String], [encryptedPassword > UTF8String]); > NSString *s = [NSString stringWithUTF8String: buf]; > return [s isEqualToString: encryptedPassword]; In the new code (lines 548-556 from NSString-Utilities.m), the password to check is provided also as the second parameter: > - (NSString *) asCryptString > { > char *buf; > > // The salt is weak here, but who cares anyway, crypt should not > // be used anymore > buf = (char *)crypt([self UTF8String], [self UTF8String]); > return [NSString stringWithUTF8String: buf]; > } Are my assumptions correct? Is this a bug? Also, just out of curiosity, are there any users who upgraded to 1.3.5 and have a working crypt-based SQL authentication? Thanks, Corrado Fiore [email protected] ________________________________ Il giorno 30/gen/2011, alle ore 22:47, Corrado Fiore ha scritto: > Dear All, > > yesterday I upgraded from 1.3.4 to 1.3.5a stable using Yum and the official > SOGo repository (I'm on CentOS with kernel 2.6.18-194.8.1.el5.028stab070.2). > > Source for authentication is an external MySQL database where passwords are > hashed using MD5-crypt (it's our Postfix backend). > > ** After applying the upgrade, login doesn't work anymore. I keep getting > "wrong username or password" error. ** > > What I did: > • Stopped SOGo / Memcached > • Issued % yum upgrade sogo as root > • Added OCSSessionsFolderURL to the defaults file > • Started daemons, with no success > • Noticed that issuing % yum update there were newer versions of Sope49-* > packages, upgraded them > • Restarted daemons, with no success. > > You can grab a copy of my GNUstep defaults file in XML format from > http://www.corradofiore.it/files/GNUstepDefaults.20110130.txt > > Installed packages: > [root@sogo /]# rpm -q -a | grep sope > sope49-gdl1-contentstore-1.3.5a-1.el5 > sope49-core-4.9-20110127_1664.el5.1 > sope49-gdl1-mysql-4.9-20110127_1664.el5.1 > sope49-ldap-4.9-20110127_1664.el5.1 > sope49-sbjson-2.3.1-20110127_1664.el5.1 > sope49-cards-1.3.5a-1.el5 > sope49-xml-4.9-20110127_1664.el5.1 > sope49-gdl1-4.9-20110127_1664.el5.1 > sope49-appserver-4.9-20110127_1664.el5.1 > sope49-mime-4.9-20110127_1664.el5.1 > > In the logfile I see: > Jan 30 22:29:33 sogod [16158]: SOGoRootPage Login for user > '[email protected]' might not have worked - password policy: 65535 > grace: -1 expire: -1 bound: 0 > > ...and in the Mysql log: > SELECT c_password FROM sogo_users WHERE c_uid = '[email protected]' > > Thanks for any suggestions, > Corrado Fiore > > __________________________ > > -- > [email protected] > https://inverse.ca/sogo/lists -- [email protected] https://inverse.ca/sogo/lists
