Best practice forum (Archived)
该论坛讨论已删除
Totara does not use any additional salt that I am aware of. We have performed several migrations from Moodle to Totara, and so long as you have the salt set the same in both sites you should be set.
Here is one thought. Have you tried logging in to the migrated Totara site with operator? The way Moodle/Totara salt works is the password field in the database doesn't necessarily mean the user has a different password. If a user had previously logged in to Moodle when perhaps there was not a salt configured in config.php, then that users password won't become salted until they log in again. What I am trying to express is that just because the password fields are not equal in the database, does not mean the users won't be able to log in with their normal password.
If there is not salt set in the config.php, then the password is just saved as an MD5 hash in the database. This looks like it might be the case on your Moodle operator account. The operator account in the Totara database appears to be salted. This is not necessarily a problem.
In this particular case, the user's deleted flag is set to 1 which means the user with username of partner will not be able to log in.
You can "undelete" the user from the "Browse a list of users" interface in Totara, or set the database flag manually, from 1 to 0. CAUTION: manually manipulating the database is typically never recommended by Totara support or Moodle, but in this case it would appear you are already doing so. Just wanted to express that direct manipulation of the DB is generally frowned upon and to use extreme caution if there is perhaps a better, more supported way via the user interface.
Hi Liz,
As I read the above you are exporting the users to csv and then importing them. The new environment will read the salted & hashed password as the actual password and salt & hash that in the db, that's why you're seeing different values. You can confirm this by opening your csv and attempting to login as one of the users using the salted password from the csv.The correct process would be to copy the actual db table (mdl_users table since that's where the login credentials live) and replace it in your new environment.I'd manage your migration in two distinct steps...1) migrate the actual user table and their passwords (to preserve their existing credentials) - this will require db manipulation, and while it is 'frowned upon' its the only way to meet your requirements of maintaining the data.2) migrate your additional fields and data using the import process (totara sync).Cheers!-T
Hi Liz,
In Moodle 2.5 the way passwords are stored has been changed to make it more secure. In Moodle 2.4 (and Totara 2.4) it is stored as a md5 hash (which looks like: d03004e6c3783948c28b001a38e9a0e0). From Moodle and Totara 2.5 onwards it is stored as a "bcrypt" hash (which looks like: $2y$10$j0RDhHH13wu4iXP73vl6pueNor2K4WSLtE/ZFrbim5E...).
When you upgrade a site to 2.5 or above all new passwords will use the bcrypt format. Existing passwords will stay in the md5 format until the user logins in for the first time after upgrade, at which point the old hash will be converted to the new format.
As long as you use the same sitewide salt you should be able to take "old" md5 hashes and import them to a 2.5+ site and it will still let the user login (at which point it will get converted to the new format).
There is some more details about the process here:
http://docs.moodle.org/25/en/Password_salting
The conversion to the new format was actually written by me/Totara for Moodle so I should be able to help if you have any issues!
Simon