Users Password “NoLongerUsed” Log In Bug?

system · November 10, 2014, 11:21pm

mike-h30 wrote on Monday, November 10, 2014:

I recently imported an openemr.sql database file that originated with an OpenEMR 2.8.3 installation (which had been upgraded over the years to the current OpenEMR release of 4.1.2 -patch 7) into Ubuntu 14.04 and OpenSUSE 13.2 servers. The Ubuntu 14.04 server is running MySQL 5.5.40-0ubuntu0.14.04.1 and PHP 5.5.9-1ubuntu4.4. The OpenSUSE 13.2 server is running Maria DB 10.0.13-MariaDB - openSUSE package and PHP 5.6.1.

Once the import was complete, I was able to log into OpenEMR on the OpenSUSE server but was not able to log into OpenEMR on the Ubuntu server with my user account nor any user that had the value “NoLongerUsed” in the password field of the MySQL OpenEMR Users table. I had another admin account that I have not used for quite some time that did not have the password “NoLongerUsed” (it still had the long coded password in the MySQL table) and I was able to log into OpenEMR with this account. Once I logged in with this admin account, I went to the User/Groups section of OpenEMR and re-entered the passwords for the users that had the value “NoLongerUsed” in the password field of the MySQL OpenEMR Users table and re-saved them. After doing this I was able to log in with my user account and the other user accounts. The password field for these users still has “NoLongerUsed” as the value in the MySQL Users table.

I looked at the Apache error logs during the time I was unable to log into OpenEMR and I see a bunch of PHP Deprecated errors:

PHP Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /var/www/html/openemr/interface/main/calendar/includes/pnAPI.php on line 721

This is very strange, I have tested this with a number of imports of current openemr.sql backup files into both servers and the passwords do not work on the Ubuntu server until I perform the steps mentioned above. I have been running OpenEMR on SUSE (SLES and OpenSUSE) since OpenEMR 2.8.3 and have decided to now explore Ubuntu.

I am puzzled as to whether this is a MySQL or PHP issue on the Ubuntu server. Can anyone shed some light as to what to look for on the Ubuntu server?

Thanks.

Mike

system · November 11, 2014, 4:48pm

yehster wrote on Tuesday, November 11, 2014:

github.com

openemr/openemr/blob/master/library/authentication/common_operations.php#L74


}




/**
* After a user's password has been updated to use the new hashing strategy wipe out the old hash value.
*
*
* @param type $username
* @param type $userid
*/
function purgeCompatabilityPassword($username, $userid)
{
   $purgeSQL = " UPDATE " . TBL_USERS
               ." SET ". COL_PWD . "='NoLongerUsed' "
               ." WHERE ".COL_UNM. "=? "
               ." AND ".COL_ID. "=?";
   privStatement($purgeSQL, array($username,$userid));
}




/**

OpenEMR is updating the value in that column to “NoLongerUsed” because the password hash (and a salt) are now stored in the users_secure table. If you upgrade the system to 4.1.2 before migrating OS as well, you’ll notice that “NoLongerUsed” already appears.

The “bug” might be in that SUSE and Ubuntu have different/incompatible implementations of the blowfish hashing function.

github.com

openemr/openemr/blob/master/library/authentication/password_hashing.php#L93


* for crypt(), sha1() can be used as a fallback.
* If the crypt function returns an error or illegal hash, then will die.
* </pre>
*
* @param type $plaintext
* @param type $salt
* @return type
*/
function oemr_password_hash($plaintext, $salt)
{
   // if this is a SHA1 salt, the use prepended salt
   if (strpos($salt, SALT_PREFIX_SHA1)===0) {
       return SALT_PREFIX_SHA1 . sha1($salt.$plaintext);
   } else { // Otherwise use PHP crypt()
       $crypt_return = crypt($plaintext, $salt);
       if (($crypt_return == '*0') || ($crypt_return == '*1') || (strlen($crypt_return) < 6)) {
           // Error code returned by crypt or not hash, so die
           error_log("FATAL ERROR: crypt() function is not working correctly in OpenEMR");
           die("FATAL ERROR: crypt() function is not working correctly in OpenEMR");
       } else {
           // Hash confirmed, so return the hash.

system · November 12, 2014, 1:57am

mike-h30 wrote on Wednesday, November 12, 2014:

Thanks for the links Kevin.

So now I see that all the users that I have in the users_secure table are the users I am not able to log in with. My workaround, which is by accident, is that I happened to have a second admin account that is not in the users_secure table. It was an admin account that was created when I first installed OpenEMR 2.8.3 and had never been used much and missed the update to the new hashing strategy. I logged into OpenEMR with that account and changed the passwords for every user in the users_secure table and re-saved them. Then everything was back to normal - including this second admin account being added to the users_secure table and password working.

BTW - I also had this happen on an older test box running SLES with php 5.2. When I upgraded PHP on that box (I had the same problem of passwords not working). So in this case it occurred on the same Linux distro (SLES) when upgrading PHP from 5.2 to a newer version.

Is there a way to change the users password on the MySQL end? I tried changing the password value in the users_secure table via phpMyAdmin but that did not work. Now I am wondering if this needs be done at the command line. If I did not have that second admin account with the old hash value password, I would have been out of luck. I guess I could just go with my “workaround” and let it be as that seems to have everything back to normal. But I am curious on how to fix this as if I did not have that second admin account.

Thanks.

Mike

system · November 12, 2014, 1:52pm

fsgl wrote on Wednesday, November 12, 2014:

Found this.

For database, see this & that.