Password encryption format changed from 2.1.1 to 2.2cvs?

[rmichael]

For testing, I migrated our journal from our production 2.1.1 installation to the 2.2.0cvs release (I think I most recently updated last week..).

I believe the default encryption format for passwords has changed from 'md5' to 'sha1', in config.inc.php.

I didn't see this in the release notes anywhere, so heads up to those attempting such a migration. (It took me a bit of time and "error_log" debugging to figure out what was happening.) Sorry if I missed this somewhere.

Actually, it would nice if Validation::encryptCredentials would try whichever setting is specified, and then just check the other in case of a bad match -- there are only two choices, so it could catch this problem easily and warn in my php log. Alternatively, if you don't want to check md5 when sha1 is specified *and* vice-versa (with more encryption options, this could get unwieldy!), at least try the config.inc.php specified value, and (IF there's a failure AND the value is not the code specified default (md5) ) THEN (check md5). Does that make sense?

Also, it looks like there is duplication (albeit in a different order) between Validation::login and Validation::checkCredentials. login() calls encryptCredentials() directly after some special casing for old email addresses (OJS1?).. but reading checkCredentials, it seems to have most of that functionality (not the special casing, however). It feels to me like login() should be calling checkCredentials() rather than duplicating the work of checkCredentials() itself. Am I off base here?

Thanks for the great work!

[asmecher]

Hi Richard,

The default hashing algorithm remains MD5, although it's possible that the default changed for a short while in CVS. In any case, I don't think auto-detecting the hashing algorithm by trying both is a good idea -- it cuts down the effectiveness of hashing for limited benefit (something like using the wrong algorithm will only come up as a result of a mistake in the configuration file, which is a rare situation).

The extra logic in the Validation class is there to help support external authentication, i.e. via the LDAP authentication plugin. Usually it's not used.

Regards,
Alec Smecher
Public Knowledge Project Team