Migrated password hashes support

Did I mention that it was really hacky? :grin:

I actually thought of that case but decided against spending more time on a solution because, after all, both packing the password data into a custom field and parsing that data would be heavily implementation specific. Although in hindsight, packing and unpacking JSON data would have been sufficiently simple to implement. :sweat_smile:

Hm. Didn’t think of that either.

I used this plugin for a migration yesterday and although it was working okay in a test migration, now on the live site it’s failing. :frowning:

They are all md5 hashes but the console shows a problem with BCrypt:

BCrypt::Errors::InvalidHash (invalid hash)
/var/www/discourse/plugins/discourse-migratepassword/gems/2.3.1/gems/bcrypt-3.1.3/lib/bcrypt/password.rb:60:in `initialize' 

Can I disable the use of this gem as I don’t need it? I commented out all lines in plugin.rb that my migration won’t need but that seems to have no effect, the error remains. :thinking:

I’ve pushed a fix.
Can you please upgrade the plugin to latest and try again?


Yes, now it is working again! :smiley: :heart:


Hi everyone,
I have been trying to migrate from vBulletin to Discourse. I was following this link to do that: Importing from vBulletin 4
I updated the import script to copy over the password hashes and salt from my vBulletin DB to Discourse DB. The database has been successfully migrated.

The problem I am having is that the old users are not able to log in due to different password hashing scheme followed by Discourse. So basically copying over those password hashes was futile.

Then I came across this plugin which would convert my old hashes to the ones that Discourse uses.
After installing this plugin, I am still not able to log in using an old user.
I am not sure where to make make the suggested change for this plugin to work:

user = User.find_by(username: 'user')
user.custom_fields['import_pass'] = '5f4dcc3b5aa765d61d8327deb882cf99'

Can anyone guide me with this?

Thanks in advance.

Hi. I am thankful for this plugin, it’s proving very useful for my Kunena4 migration.

But I ran into problems which were quite hard to understand - only after setting up an IDE and debugging through the code I was able to figure out why my logins weren’t being accepted.

The passwords I was trying were right, and the hashing was also working fine. The problem was with Discourse’s password requirements:

  • I had to go in Admin / Settings / Plugins and check migratepassword allow insecure passwords

  • I had to go in the database and run UPDATE email_tokens SET confirmed = TRUE to bypass the email tokens mechanism (note that my approach was a bit brute force here - if you have existing users you’re not migrating, use a less aggressive approach)

The difficulty was especially with the first part, because I had no clue why the login was being rejected. I hope this helps someone.

And again, thanks for the plugin! :slight_smile:


This is more an issue with the importer, independent of the migratepassword plugin.



This plugin is just what I’m after, can it be used with Drupal?



It’s not listed in the plugin:


You’d need to do some testing and/or change the plugin to match Drupal’s password encoding (or maybe one of those forums is Drupal-based and it’ll just work).

1 Like

Thanks @pfaffman

I’ve done some testing and can confirm that it doesn’t work with Drupal 7, which apparantly uses SHA-512 according to Drupal 7: Secure password storage by default at last | Jon Cave

I’ll create a PR if I’m able to add a compatible one.



Hello :wave:

I migrated a whole lot of content from bbPress over to my discourse installation. I can see all posts and users and stuff. But my users can’t login using their “old” password data from my WP site. I installed the plugin, its listed in my plugin section of my admin area. I checked all the available check marks.

Still: nobody can login!
I also have no idea where to apply the given code from the plugin’s readme:

user = User.find_by(username: 'user')
user.custom_fields['import_pass'] = '5f4dcc3b5aa765d61d8327deb882cf99'

Also I have no idea what exactly is meant by alternative password hashes talked about in the readme.

@michaeld could you provide some more guidance on how to use the plugin?

As far as I recall the bbpress importer supports the plugin, so you did everything right and that is all you would need to do.

1 Like

Oh my god, after some more testing it turned out that it actually worked. The problem was a changed password when I tested it :man_facepalming: Sorry! Thanks for the great plugin! Made my life a lot easier!


Hi, I’m having problems making this work. I’ve created a custom field import_pass and installed the plugin. Ran the import script once again on my SMF database but with no luck, no one can login afterwards. On the custom field I can see just a “-“ instead of some hash.

Like other users pointed out before, not sure what do with this:

user = User.find_by(username: 'user')
user.custom_fields['import_pass'] = '5f4dcc3b5aa765d61d8327deb882cf99'

Appreciate any guidance Does this code go in the smf2.rb import script file or what?

That won’t work. But there is no need to install the plugin during import, or to create a custom field manually. It should be handled by the SMF2 script already. So something else is up.

The code is there as an example for script authors. It’s already in the SMF2 script.


Thanks. That’s great. So you mean, if I remove the manually created custom field and just keep the plugin activated, then it should work by itself and pick up the password hashes when it needs too.

Is there a log we can check to see why the plugin isn’t doing what is supposed to?

The plugin takes care of interpreting and using the custom fields that have been set by the importer. If the custom fields are empty or not there, then it is not an issue with the plugin, but an issue with the importer.


Should the plugin be installed before or after the migration? Or it doesn’t change anything?

TL;DR: after.

You should install the plugin on the instance that is actually running the migrated forum.

We have seen instances where the plugin caused issues when it was installed on an instance that was actually running the migration script, so we recommend against installing it there.