vBulletin SHA1 Workaround?

[agallian86]

I've upgraded to vBulletin from SMF, and am looking to not have my users reset their passwords. The problem is that vBulletin uses an md5 hash while SMF uses SHA1.

So, my theory is to, during the login process, write some php code (or something else?) to essentially:
-capture input password
-convert password to md5 and check with db, if true -> login (the typical behavior), else...
-convert password to sha1, check with the db, if true ->...
-save inputted pass as an md5 hash, go back to step 2.

I've read conflicting things about how many md5 calls there are and where they are relegated to. Can anyone point out a specific place to modify (i.e. member.php) and/or give an example of how to accomplish what I need?

Thanks.

P.S. I wrote tech support on vbulletin.com and my ticket assistance said it was possible and to refer to you guys for some code modification help.

I've been informed (and learned via searching) that I need to pay most of my attention to the vbulletion_md5.js, login.php, and functions_login.php files.

I am not an experienced coder (for these languages at least) and could use some help implementing a SHA -> MD5 workaround; the workaround doesn't have to be done the way I've explained above by any means, as long as it's transparent to the user and they can login to their existing SHA'd password.

[Dismounted]

Problems List

1./ vBulletin "zaps" (encrypts) the password before it even gets to the server, making it impossible to capture without changing a heap of things.
2./ Even if you did get past that, anyone could login as anyone and gain control of their account...

[agallian86]

Originally Posted by Dismounted

Problems List

1./ vBulletin "zaps" (encrypts) the password before it even gets to the server, making it impossible to capture without changing a heap of things.
2./ Even if you did get past that, anyone could login as anyone and gain control of their account...

1. Why couldn't I just change the calls from md5 to sha? and/or add funtionality to the checking? (check against md5 and sha hash)

2. No, they couldn't. It would check their pw against the hash stored on the db, first as an md5 and if it didn't match try to hash it as a sha and if that didn't match then your login failed, if it did match then you store it as an md5 hash so it doesn't need to be compared each time as md5 then sha (i.e. usual vbulletin functionality).

I've been told specifically by vbulletin staff that it would work and not take tons of effort, trouble is, I don't have the faintest idea of how to code it and they're not authorized to help with code modification, and I know someone here can help point to the right direction.

[Marco van Herwaarden]

Originally Posted by Dismounted

1./ vBulletin "zaps" (encrypts) the password before it even gets to the server, making it impossible to capture without changing a heap of things.

Although not advised from a security POV, you can set 'DISABLE_PASSWORD_CLEARING' to true in your config.php, and the passwords will be passed to the server unencrypted.

[agallian86]

Originally Posted by Marco van Herwaarden

Although not advised from a security POV, you can set 'DISABLE_PASSWORD_CLEARING' to true in your config.php, and the passwords will be passed to the server unencrypted.

Seems like a great step to what I need accomplished.

Though, since it would be now sent in plain text, would it be possible to call an SHA hash to compare against the SHA hash I have stored on the database (from SMF)? And then have that authenticate old users. And call an MD5 hash to compare against an MD5 hash stored in the database (from vBulletin).

Basically something like:
-capture pass in clear text
-sha hash it, if it matches the pw on the db allow login, else
-md5 hash it, if it matches the pw on the db allow login, else
-reject login credentials

I'm not interested in getting the passwords for my users per se, I'm interested in being able to compare old users passwords to their SHA hash from the old forum I was using and then (optionally) if that password works setting it to replace the pw field with the md5 hash so that eventually I could do away with the SHA hashing once everyone effectively gets their passwords md5'd. New users would simply work with the normal vBulletin hashing scheme and not have any issues.

I hope I'm conveying my need clearly, thanks for the directions thus far guys!

[El_Muerte]

Originally Posted by Marco van Herwaarden

Although not advised from a security POV, you can set 'DISABLE_PASSWORD_CLEARING' to true in your config.php, and the passwords will be passed to the server unencrypted.

or you extend the code to include both md5 and sha1 passwords, of course you'll need a javascript sha1 routine

[agallian86]

So, I create something along the lines of vbulletin_sha1.js, which php files would I need to modify in order to run the comparison at a user's login? login.php and function_login.php?

I've got mixed information about where the md5 calls are performed.

[Zachery]

Hate to say it but the easy way out seems to just have users change their passwords

[Dismounted]

Originally Posted by agallian86

So, I create something along the lines of vbulletin_sha1.js, which php files would I need to modify in order to run the comparison at a user's login? login.php and function_login.php?

I've got mixed information about where the md5 calls are performed.

You would hook the login process. Read up on vBulletin Plugins and how they work .

[agallian86]

I've successfully gotten the db to store a newly created password in plain text (though this is an intermittent success as I don't want to keep it in plain text), however, the DISABLE_PASSWORD_CLEARING doesn't seem to be working as I cannot login to accounts with the unhashed password set regardless of the true/false setting for that.

In theory since the pw is now stored on the db in plain text and setting DISABLE_PASSWORD_CLEARING to true should compare the pw as plain text, now ONLY the non-hashed passwords should be logging in, correct?

Not sure why this simple set of mods is only working halfway and screwing up on the eaiser part (not zapping the pw)