Migrated password hashes support

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.

Rich

3 Likes

Hello :waving_hand:

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'
user.save

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!

2 Likes

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'
user.save

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.

3 Likes

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.

2 Likes

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.

4 Likes

Hi,

Has anyone tested with password hashes from Auth0?

I can’t just test because their password hash export is a paid customer service, just wanted to know if anyone tried before going this route myself.

Looks like their passwords are hashed using bcrypt with 10 salt rounds.

Thanks.

2 Likes

Hi there, by any chance has anything changed regarding Drupal 7 support?

Whoops, 2 year old question that I missed!

bcrypt should be supported regardless of the number of rounds, as long as the rounds are encoded in the usual way ($2a$10$...)

No, that code has not been touched in over 3 years.

1 Like

We migrated a forum to Discourse several years ago using the migratepassword plugin. Is there a way to check how many of our users are still using the legacy password hashes from our old forum?

Technically, a user is not “using” the legacy password hash.

When a user logs in for the first time after a migration, and the password does not match the Discourse password (which will be a random string of characters initially), the plugin does its work.

  • it checks if the entered password does match the import_pass custom fields using all hash methods it knows about
  • if it finds a match, it saves the password to the user and then removes the import_pass custom field.

So after a few years, only the users who did not “use” the migrated password to login will still have a import_pass custom field.

a) they never logged in (you can check that with the last seen date)
b) they didn’t use the migrated password but logged in using email, a different auth method, or they have reset their password

:warning: I just realized that situation b can introduce a security issue. If a user does not remember their password and changes it, or if they use another auth method, the migrated password hash will still be there and can still be used next to the new password. I have just pushed an update to the plugin so it clears the import_pass custom field on every successful login.

So going forward, the import_pass custom field will only be there for users who never logged in.

2 Likes