Possible bug in "reset password" function?

[enigmaticx]

When an admin attemps to reset another user's password via usermgr.php, the user is no longer able to login. Looking at the database itself reveals that the plaintext password has been saved to the database, rather than the md5 hash version of it.

The config value 'enable_encrypted_passwords' is set to 1 in the database. I can see that all existing accounts have their password encrypted in the database.

This applies to cpg1.4.3 - this is not an upgrade from a prior version, but a clean install.

[Nibbler]

Unable to replicate, works fine for me.

[Joachim Müller]

@enigmaticx: please post a link to your site.

[Blueiris]

@Nibbler: I can confirm that this is a bug. Ran across this issue in testing cpgNG this morning, and reported it in that subforum. Also found it in cpg143 after testing that.

If the admin uses the User manager to reset the passwords for one or more users by checking them in user manager and then using the dropdown box and text entry field at the bottom of the User manager, the password is entered into cpg143_users as plain text, regardless of the setting of enable_encrypted_passwords in cpg143_config.

If enable_encrypted_passwords is set to 1, when the user tries to log in with the new password the login fails.

I think the problem is in delete.php at line 630, where the new password is being set without testing the value of enable_encrypted_passwords.

// set this user's password
                            $new_password = addslashes($_REQUEST['new_password']);
                            cpg_db_query("UPDATE {$CONFIG['TABLE_USERS']} SET user_password = '$new_password' WHERE  user_id = '$key'");
                            printf($lang_delete_php['password_reset'], '«'.$_REQUEST['new_password'].'»');
                            print '</b></td>';

[Abbas Ali]

Confirming the bug. Fixed and committed to stable and devel.

@enigmaticx and Roberta: Thanks.


Abbas