IPBoard to Vanilla - partial user migration (without password)

yoda

Hi all,

Currently I'm admin of a +6000 user community within IPBoard 3.x, which I would like to migrate into Vanilla. I've searched a lot about migrations between the two softwares, and found nothing sufficiently reliable to make so happen, so I thought about splitting the proccess into several phases myself.

The first item I'll try to migrate is the community members / users, but I figured I couldn't just migrate the password fields since the encryption method should be logically different, so I thought : what if I migrate what I want from the users except their password, and somehow ask for the password when the user tries to login on vanilla for the first time?

Of course I can't just ask for a password and accept it as the right one (or the right user accessing that account), so maybe one option would be to use the user's already stored email to send them a link that would route the user to a password reset page.

I'm kind of new to Vanilla yet, played just a bit with it in v1.x, so bare with me if the question is dumb. If not, I'll appreciate some feedback on how to procceed on this matter, and / or if there's already a way to achieve it.

Thanks in advance!

DirtyDog

Have you investigated the Vanilla porter? I'd be interested in hearing your reasons for this migration if you would care to share.

yoda

Vanilla Porter doesn't directly work with IPBoard as far as I could check, and the only workaround I found was to migrate from IPBoard to another supported software by the Porter plugin and go from there, and I don't feel like going that way, honestly.

About my choice of Vanilla over IPBoard, it's mostly an economic issue at the moment, but as a developer, the ability to hook the system I work with, thus creating a better user experience, is a big plus. Vanilla allows me to do that in a fairly easy way, with human-readable coding practices, simple approaches and easy to hook. From a user point of view, I think people should see what they want to see (so that they actually use internet and not get stuck in it), and Vanilla has a KISS approach that allows users to use the software to its fullest extend disregarding learning curves at some point.

UnderDog

You have a couple of options.
I'm sure you will want to move the forum content to Vanilla after you've moved the users and are completely happy with that phase.
In that case I would recommend to ... uuuhm... write a little code inside Vanilla. All those importer scripts of the 'supported' forums are inside Vanilla and you can add yours to it :-)
That's one option.
I saw you played with Vanilla 1.x but Vanilla 2.x is waaayyy different, so start playing with 2.x first.
Actually, there's a new version going to come out (Early Beta stage first), which is 2.1 and it will change some of the themeing and probably also the inner workings of Vanilla.
Enough said about Vanilla. What do you want to do with the users after you've moved them over to Vanilla, what are the next phases?

When you decide to make your own importer piece inside Vanilla, use the Porter plus to convert all from IPB to Vanilla : https://dl.dropbox.com/u/15933183/porterplus/porterplus.php

yoda

If I were to do such thing (create the IPB importer), it might be better to wait for v2.1 to come out (or if the beta is matured enough, that would be fine). I'll have to think about it though.

Is there any prediction about v2.1 alpha release?

Also, I still have the question of how to procceed with encrypted content such as the users passwords?

UnderDog

@yoda said:
Also, I still have the question of how to procceed with encrypted content such as the users passwords?

I see in this post : http://vanillaforums.org/discussion/comment/173501/#Comment_173501 the user modified the passwordhash class a little to match his custom hashing.

There is no prediction about the 2.1 alpha release. There's branches on gitHub and they seem stable to me.

The develop branch and release2.1b1 branch are closest to the beta that will be released. PM me if you want to try those out. I don't know about the changes between now and the real 2.1. Lincoln made an announcement about it : http://vanillaforums.org/discussion/22043/about-the-vanilla-2-1-release-cycle

if you would like to document anything you find for the public, our Wiki is the place (Url in my sig)

yoda

Hey,

So, IPBoard 3.x passwords hashes are resultant of a custom salt (different for each user) and a password, so to Import I would have to create a custom field in the users database and hook the login system to check this special case. Does it sound right?

UnderDog

Sounds right, but are you sure you want to go that route? I know that extra salting is more secure, but now you have an extra field in the user table you need to maintain.

x00

Salting doesn't require an extra field typically it is included in the hash if it is variable. That is to stop a rainbow table attack.

UnderDog

@x00 said:
Salting doesn't require an extra field typically it is included in the hash if it is variable. That is to stop a rainbow table attack.

I know, but this:

@yoda said:
So, IPBoard 3.x passwords hashes are resultant of a custom salt (different for each user) and a password

Gave me the clue that the hashes are different for each user, ergo a separate value for each user, so maybe an extra field for each user.

I was involved in a system long long time ago where we salted per user (separate field in user table) and also salted that salt (lol).
That's why I concluded that when there is a salt per-user, that there must be a field in the user table for each user :-)

x00

What I mean is the salts are variable, but even so you don't need to use another field you can include them in the the same field.

yoda

@UnderDog got it right, there's a different salt for every user in the database, and the resultant password is something like md5($salt).md5($password).

There is no way I can mix the two without any user confirmation, so import those passwords becomes meaningless unless I can hook the user's table and add an extra field.

x00

I think there was a misunderstanding of what I was saying.

Usually it is something like $salt.'$'.md5($salt.$password) or md5($salt.$password).':'.$salt or the salt is encoded to protect against a rainbow attack.

Note it is md5($salt.$password) not md5($salt).md5($password) or md5(md5($salt).md5($password)). The first has the higher strength.

if you look at Django/Jooma/mybb/IPB don't use a different field. It incorporates all in one. Even Vanilla uses phppass which stores the salt in the same field but in a more complex way.

IPB uses

   function CheckIPB($Password, $StoredHash) {
      $Parts = explode('$', $StoredHash, 2);
      if (count($Parts) == 2) {
         $Hash = $Parts[0];
         $Salt = $Parts[1];

         $CalcHash = md5(md5($Salt).md5($Password));
         return $CalcHash == $Hash;
      }
      return FALSE;
   }

Note the green line where the parts are exploded.

Note the red line which is kind of sucky but can't be helped. It is not the best to put it back into md5, but reasonably sufficient.

All that is needed is for the the hash method to be supplied,in a field so it knows the format.

UnderDog

Now it's a matter of choice. It's ok to have that extra field in the user table or maybe follow what x00 is saying, but you can also choose to reset your users passwords. Will that piss them off?
I would certainly go for a custom hashing anyway (see the forum post in one of my earlier comments), so it might become custom work anyways.
Am I contradicting myself here?. Let's see how you're doing with the conversion first, that's how we all started, didn't we? And guess what? We have the creator of porterplus in this discussion! (x00).

Anyways. I might have forgotten to say that you first install the plugins you most likely want to use and then convert all your IPB content (BBCodes??, Tags??) to Vanilla.