I have quite complex migration for some legacy non drupal site to migrate it into D7. The whole migration works fine but it turned out that source user passwords are salted and hashed with MD5. Because they are salted I can't do this in my migration class:

 $this->destination = new MigrateDestinationUser(array('md5_passwords' => TRUE));

I've found this solution which boils down to reimplementation of original hashing algorithm in new drupal site. I don't like this solution because it decreases security of the site and throws away whole D7 password hashing code.

Something tells me that the only way to migrate those old passwords and keep the drupal hashing algorithm is to copy-paste whole includes/password.inc and add "temporary" hashing algorithm from the old non-drupal site in similar way drupal core handles old MD5 passwords without salt.

Or maybe there is a better way to migrate those old passwords?

1 Answer 1


I don't like this solution because it decreases security of the site and throws away whole D7 password hashing code.

How does this decrease security? The D7 hashing function is pluggable, you can migrate the fields without (re)hashing them by setting $this->md5Password = FALSE and then using your own hash function from the legacy system, as commented on in the issue you posted:


You're still using the Drupal API to perform authentication and more than likely the legacy hashing technique while not stellar is probably not brain dead.

Now, if you don't like side-stepping the default Drupal7 password semantics -- then don't. Or do it for a temporary amount of time as you mentioned and inform your users of a pending system-wide password reset. This happens alot all over the net even recently on Drupal.org.

You may force all site users todo a password reset and setup strict password enforcement using the Password Policy module:

A password policy can be defined with a set of constraints which must be met before a user password change will be accepted. Each constraint has a parameter allowing for the minimum number of valid conditions which must be met before the constraint is satisfied.

Example: an uppercase constraint (with a parameter of 2) and a digit constraint (with a parameter of 4) means that a user password must have at least 2 uppercase letters and at least 4 digits for it to be accepted.

  • What I actually did was to copy-paste whole password.inc and modify a bit user_check_password() function. I've replaced this line $password = md5($password); with my legacy hashing algorithm and still used new MigrateDestinationUser(array('md5_passwords' => TRUE)); during migration. This allows me to retain the drupal password rehashing on login feature. I'm accepting your answer but it would be great if you could include this solution for other people. Oct 3, 2014 at 7:03
  • that's 1 way, you will need to manage that file change during any drupal upgrade (but that's not too bad, like any patch). I've previously answered questions on howto implement your own custom 3rd party login integration through the drupal login form -- this question is similar to that. At this time I see no need to provide example code for this as the issue queue outlines the steps necessary. happy you got a solution that works.
    – tenken
    Oct 3, 2014 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.