After migration passwords...



  • @a_5mith's suggestion is yet another way to do this, but at the end of the day if you want to convert the passwords they have to become plain text along the way...

    Also, regarding their privacy...if they are md5 they're basically as good as plain text anyway, so no reason not to convert them...

    Otherwise, you should really consider an sso-plugin or login warning...there's probably no other way...

    You basically have two options:

    1. Inconvenience yourself and convert the passwords
    2. Inconvenience your users and have them update their passwords

    Either way someone will be inconvenienced...it sucks but it's true...

    I would doubt someone is going to provide a one-click fix for this.



  • @mootzville said:

    @a_5mith's suggestion is yet another way to do this, but at the end of the day if you want to convert the passwords they have to become plain text along the way...

    Also, regarding their privacy...if they are md5 they're basically as good as plain text anyway, so no reason not to convert them...

    Otherwise, you should really consider an sso-plugin or login warning...there's probably no other way...

    You basically have two options:

    1. Inconvenience yourself and convert the passwords
    2. Inconvenience your users and have them update their passwords

    Either way someone will be inconvenienced...it sucks but it's true...

    I would doubt someone is going to provide a one-click fix for this.

    IPB use the MD5(MD5($salt) . MD5($password)) hashing algorithm. IMO the better way would be to try logging into the old database first with the IPB algo, if it succeeds then hash the new password with bcrypt and store it. Not sure if you can hook into the login system so it will probably require editing the source.


  • GNU/Linux Admin

    @xbenjii Yes, I suppose that is the difficult part of migrating passwords, is that all of these old forum softwares use different ways of hashing passwords (all using md5, of course, heh).

    Not just plain MD5, but some with salts, some with md5 hashed salts, some with salts pre-pended then hashed, some post-pended, some salted a whole bunch of times... the list goes on to infinity XD


  • Plugin & Theme Dev

    @Technowix

    Part of your conversion to NodeBB is a more secure encryption algorithm. Not being to convert passwords is not an expensive price.

    Any other solution will take some time and wont be perfect nor as secure as NodeBB was designed to be.

    Don't get me wrong, I am not against a plugin-solution (SHA1 then fallback to MD5) if the users want to have it but I don't think it's that easy

    @a_5mith way's is possible, but the problem that you need that MD5 comparison to go through the original forum logic (adding salt and such), just like @xbenjii and @julian mentioned.

    I guess one way I can do that is the following (I am also brainstorming here so it's verbose)

    • While importing, I can store the old MD5 hash next to each user's record in the NodeBB DB i.e. user._imported_password - I do it anyways now, (temporarily) for other fields such as _imported_uid, _imported_signature and few others to convert post the import process.

    • Each exporter module would need to add an extra api function, i.e. MyExporter.comparePassword the implementation of this one is forum specific, so IPB would be different then SMF, and PHPBB etc..

    • use a NodeBB filter:user.login hook to intercept the login process and compare the user entered plain text password to the one stored _imported_password, ONLY if the user.password is NULL && _imported_password is still there && nodebb-plugin-import is still activated && exporter.comparePassword is implemented.

    • if the password comparison passes, as @a_5mith suggested, update the user's password using the code NodeBB functions, if not, let NodeBB tell the user that the password is incorrect.

    • Then introduce some sort of action:password.updated (would need core NodeBB changes) hook to fire another action in the plugin that deletes the user._imported_password and never talk about it again, this way if user doesn't even bother with logging in and decides to reset their password, the same logic occurs anyways and the _imported_password also gets deleted.

    I can implement all that in few days (but cant start till few weeks), however this solution is ONLY possible if each ExporterModule implemented the comparePassword function correctly, which means digging into each Forum source and write it in JavaScript, this is the challenging part really and if you're willing to help, I'll take it.

    As of today

    The importer, by default (there is a hidden random password generator config) will create all users with null passwords, so when they try their new passwords, it wont work, and they are forced to reset it.

    This is what I suggest you do if you want to convert before all this

    After importing, open the "Post-Import tools", download users.csv and use this web tool to email your users an "Announcement" email introducing your re-designed forum with the caveat that everyone needs to reset their passwords "in order to increase security"



  • Ewh, this look fancy :') but hard yes, this give you even more work 😕 !
    Also, you app look fancy, and i think i will do that ^^' but, if anybody don't look his mail before goind on the forum... arh


  • Plugin & Theme Dev

    I will attempt to do that as soon as I can take a breath from my current work load.
    https://github.com/akhoury/nodebb-plugin-import/issues/64



  • @bentael Your a god, thank ! 🙂



  • What's up on it @bentael ? 😄


  • Plugin & Theme Dev

    nothing yet man, I am seriously buried with work between my day job and the nodebb importer backlog. Maybe in Feb I will take a look.



  • @bentael Okay, thank ❤ ! We can wait one month more i think 😛



Suggested Topics

| |