The part that I get caught up on is how to authenticate a returning user without keeping the insecure hashes.

We could do name matching, but that would make it really easy to hijack an existing account. We could authenticate by using the profile e-mail, but that might be out of date and then the user is kinda stuck since they can't create a new account since there is an existing one.

I don't know. It's a tricky problem.

You keep the old hashes (for a short period of time). The first time a user logs in, you prompt them for a new password and/or generate a new hash. After the grace period has expired, the old passwords are purged. Then a user would have to either use their account email address, or the admin contact form, same as always.

I just don't want there to be so much friction that we lose people during the board transition.

A grace period could work.

Were you saying you were willing to help with migration, Tom? If you need access to the code, just get a gitlab account and I can hook you up.

OK, I created a gitlab account, which is the same username as my email address.

You're all added to the project and stuff.

Made an update. You can send messages to an admin now. In the admin section, there is a message tracker and some simple analytics.

I think the next step is to work on migration. I need to see if I have access to the current database so I can make some migration code.

I also need to modify the login code so that legacy passwords can be used once and then a new password will be forced. I think I'll let the same password be used since the point will be changing from a MD5 hash to a salted bcrypt hash.

Thank you so much for all of your hard work and effort on this, Gud!

I have access to the current database. I was trying to figure out how to upload stuff into the new database.