Migrate user passwords salted and hashed with md5 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-&gt;destination = new MigrateDestinationUser(array('md5_passwords' =&gt; 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?
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-&gt;md5Password = FALSE and then using your own hash function from the legacy system, as commented on in the issue you posted:

https://www.drupal.org/node/1326450#comment-5192996

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.