During users migration, password re-hashing slows down the process with a factor of multitudes. That's just how it is. For sites with less users, this might not be a big problem, But in my use case, I'm migrating 2,6M users. I already took the migration process out of the migrate framework which allows me to import users' base fields in about 30 minutes (opposed to 6 hours without hashing!) - and we haven't even tried running MySQL in RAM yet.
I've created a separate script that starts a few seconds after my user migration starts and only does the password hashing, but even then it would probably take a least two days before that is finished.
So to minimize downtime, I've came up with this idea:
- swap out PhpassHashedPassword and use my own class
- during my migration, prefix the existing D6 password with say $D6$ (or something else say $MI6$)
- add some lines in my swapped class, in PhpassHashedPasswordSwapped::check - if I find my custom prefix, use old style D6 password checking
- start the separate script todo the hashing. At some point, the site might even come back online, and users can login with either the D6 style, or with the new style already
- Once the hashing script is done, swap out the service again
Now, as a first step, I'd propose to
- Add an configuration option to the user migration to skip user password hashing check
- Add some extreme red flag so that when you surf around on the site you get warnings all over the place that the password hashing has not run yet. Note that users won't be able to login anyway, but if your database is compromised, there's a lot of hackers going to be happy to have md5'd passwords
- Add a separate password hashing migrate script
I would not go so far to introduce my current implementation because that might be a step to far and to dangerous.
Thoughts ?