User and Password synchronization

[nullified]

Hello everyone,

I'm currently looking at setting up a vBulletin for a large userbase (30k people) based on the users in a proprietary management solution. I, essentially, have three issues:

(1) Nightly Synchronization
(2) Passwords
(3) Rights Management

I do have PHP experience and have written a few things for vBulletin, but truth be told, I haven't touched the code for years (mostly, I hacked vB 2 and early vB 3) so please bear with me.

(1) Synchronization
I don't think this would be too much of an issue to program: we already push userassword:email:auxilliarydata lists to our servers over an encrypted connection and feed them into our various applications. It shouldn't be too difficult to check that list against the vBulletin user list and add those people who are new/whose password changed. We can gurantee integrity of a number of fields and while there are a couple of edge cases, they are managable.
However: is it a bother to block changing the password and email address inside of vBulletin?

(2) Passwords
This is the big issue I see: we don't store passwords in vB's fashion.
We currently store passwords as md5 and sha256.

After having a cursory glance at function verify_authentication I'm actually somewhat hopeful that not all is as difficult as I had feared because if I read vBulletin's code correctly, it actually catches passwords that are "merely" md5 hashs instead of salted hashes -- if that is the case, would it be possible to simply write the md5 hashs with every synchronization and rely on that fallback to make it smooth for the users (it's not nice, but our overall ecosystem is secure enough that I don't really see the harm)

(3) Rights Management
This, too, shouldn't actually be too difficult: on synchronization, we check whether a user still exists on the list and, if he doesn't, we delete him. Right?

As said, I'm aware this does require some coding and I can put that time in, but I just want to get a little bit of feedback from people who have touched the code in the last couple of years to see wether there's an easier way or to get some pointers to get this done more quickly (i. e. am I reading verify_authentication correctly)

Regards,

null

[kh99]

Originally Posted by nullified

However: is it a bother to block changing the password and email address inside of vBulletin?

I don't think so. I think you can edit template USERCP_SHELL and take out the link to "Edit Email and Password", which looks like this:

<li class="{vb:raw navclass.password}"><a href="profile.php?{vb:raw session.sessionurl}do=editpassword">{vb:rawphrase edit_email_and_password}</a></li>

or I suppose if you wanted to you could change it to link to somewhere else. Also, you'll want a plugin using hook location profile_start that checks for $_REQUEST['do'] == 'editpassword' or $_POST['do'] == 'updatepassword' and does something like print_no_permission().

...if that is the case, would it be possible to simply write the md5 hashs with every synchronization and rely on that fallback to make it smooth for the users

I'm not sure I understand this, but the password stored in the vb database is md5(md5(password) . salt). verify_authentication() is written to accept plain text passwords or md5(password), I think because if a user doesn't have js enabled there's no choice but to send the plain password. You can also define the value DISABLE_PASSWORD_CLEARING (like in the config.php file) so that the plain text password will be sent even if the md5password is also sent (otherwise only one or the other will be filled in).

Also, in case this matters to you - if the user has checked "remember me", the password is saved in a cookie and I don't believe verify_authentication() is called in that case.

[Zachery]

The cookies password hash is also unique to the site and hash another salt/md5 added to the mix.

[nullified]

Hello kh99, (and Zachery /edit)

thanks for your reply:

On 1: Yeah, I thought that might be as easy as that, thanks. :-)

On 2:

Yes, that wasn't very clear (and I actually made a thinking mistake that muddled it further): in essence, I was thinking about wether it would be possible to simply write md5(<md5hash>) to the password field in the database and remove the salting from verify_authentication.

Then again, a more practical option (that is, one that doesn't break a vBulletin function) should be:

When a new user is added during nightly synch:
1. Call register_addmember with md5 from synchronized file

/edit (see below)
1. Register user and generate random password
2. Read his salt
3. Read his md5 hash from the synchronized file.
4. Salt this md5hash with his salt.
5. Write this to the password field.


On nightly synchronization:
1. Read password and salt field from vB database
2. Read synchronized file and get his md5 hash from there
3. hash and salt md5 from synchronized file
4. Compare the two and replace hash in password field if they don't match.

Would that work?


/edit

Actually, I don't even need to go that far, I just had a look at the API and register_addmember actually allows you to specify plain md5 --> problem solved there. There isn't by chance a setpassword API call that accepts md5, is there? I don't really mind writing the 30k passwords every night, at least for a proof of concept. ;-)

/edit (again)
There is profile_editpassword and profile_updatepassword -- those might actually work, but I haven't found documentation on them (I just looked through the files now)

[kh99]

Originally Posted by nullified

There isn't by chance a setpassword API call that accepts md5, is there? I don't really mind writing the 30k passwords every night, at least for a proof of concept. ;-)

/edit (again)
There is profile_editpassword and profile_updatepassword -- those might actually work, but I haven't found documentation on them (I just looked through the files now)

Depends on what you mean by API, I guess. I think, as you pointed out, the profile.php set password can take an md5 password, but it's meant to be called by posting form data. If you were writing your own script you could use the user data manager, and in that case I believe you can set a user's password by providing the md5(password) value.

[nullified]

If that's the case, then everything is simple. My original worry was getting from the md5 that I have to the one vBulletin understands (with salt and all).

If I can simply write md5 (as is the case with the addmember function) and update the password, again writing md5, with the user data manager, then everything suddenly becomes so, so easy.

Thank you very much, a project that I thought might take me a couple of days reduced to a couple of minutes, hours with proper debugging and stuff. (I actually created a POC of the addmember registration just now and will try to update passwords via the user data manager as soon as I find it )

[nullified]

I don't know if anyone is interested in it, but I thought I'd add this because I did find that a few people have been looking for that functionality over the years.

I've completed a relatively robust system for my purposes and I'm currently working to make it as simple as possible to accomodate other data schemes. It handles synchronization and updating pretty well and I hope I can complete it next week. :-)

[biocyberman]

I am interested in this too. So what is the progress, nullified?