Turn off MD5'ing of passwords

[oO RusH Oo]

Hello everyone, :]

I've had quite a few bots attack my sites recently, either posting a whole stream of adverts, or trying every exploit in the book against my sites.

I'm fed up, so i've decided to do something about it!

Their are a few tools which generate these bots, most of them use dynamic usernames, however i don't belive that they dynamically generate passwords.

Even if they are, i can make a list of e-mail addresses/IP's/common proceedures that these bots use, and use it to block out bots in the future.

So basically i'm making a vBulleting Honeypot - but to prevent ligitimate users from signing up, i've made it very clear in the registration letter that the forum is not real, and if they don't verify their e-mail address their password will be deleted within the hour.

Only problem is, it would take ages to decrypt the md5'd passwords in the database of the bots, and if i have four or five bots a day attack my site, it just isn't realistic...

A much better idea is for vBulletin to just compair plaintext passwords, and i could scan through the mySQL DB and spot any similarities that way.

I know older versions of vBulletin didn't use MD5, but reverting back to this is too complicated for me :P

Could anyone give me any pointers?

Cheers guys,

~ John

[ConqSoft]

You should still be able to scan through the database to spot similarities, even when they're encrypted, right? They're all encrypted the same way.

[oO RusH Oo]

Yup, that's true... but if vBulletin ever decide to change their salt or instead of using md5 use sha1 or something, my data will be useless.

Surely taking features away form the forum would be easy...?

Or if not, couldn't you save all input passwords used to log in into a file on the server?

I dunno, like, "vb_login_password" mailto:admin@website.com or something?

I know nothing about php - i was really hoping someone here would know what to do.

[Marco van Herwaarden]

Originally Posted by ConqSoft

You should still be able to scan through the database to spot similarities, even when they're encrypted, right? They're all encrypted the same way.

Not true, each user has a Salt that is used to encrypt the password.

To answer the original question, you can add the following to your config.php to get the plaintext password. This is not adviced on a production board!!

define('DISABLE_PASSWORD_CLEARING', true);

[oO RusH Oo]

Thank you very much mate, this is exactly what i was looking for!

I'd also second that this would be a really really bad thing to do on a proper forum.
To get into the admin control panel you need a password - you can't use the MD5 hash like you can in a forum.
For this reason it's vitally important that you make sure you encrypt all passwords. Not doing so is probibly the biggest security mistermeaner that you can possibly do, second only to posting your ftp details into the welcome page :P

Wait, are you sure this is the right code?

I just did a search with it and the comment next to it is:

// you may define this if you don't want the password in the login box to be zapped onsubmit; good for integration

$show['nopasswordempty'] = defined('DISABLE_PASSWORD_CLEARING') ? 1 : 0; // this nees to be an int for the templates

Are you sure this will prevent hashing of the password...?

[Kungfu]

Originally Posted by oO RusH Oo

$show['nopasswordempty'] = defined('DISABLE_PASSWORD_CLEARING') ? 1 : 0; // this nees to be an int for the templates[/CODE]


Are you sure this will prevent hashing of the password...?

$show['nopasswordempty'] = defined('DISABLE_PASSWORD_CLEARING') ? 1 : 0;

this is just seeing if DISABLE_PASSWORD_CLEARING is true, if it is it returns 1, if not it returns a 0.

what Marco said was to make it true
define('DISABLE_PASSWORD_CLEARING', true);

[oO RusH Oo]

Yeah, but looking at the commenting which goes with that function, it doesn't seem to have anything to do with encrypting the passwords - if you don't want the password to dissapear when you hit back (after clicking login), then you can use that function to keep it there.

I don't think it prevent's hashing of passwords at all ~__~;

The closest i think i've come so far is with THIS thread...

[Brad]

It prevents the hashing of the password by the javascript in the navbar. Meaning the password is sent to the server as plaintext.

It's half the battle, the rest deals with hacking this bit of code from class_dm_user.php;

PHP Code:

        /**
    * Takes a plain text or singly-md5'd password and returns the hashed version for storage in the database
    *
    * @param    string    Plain text or singly-md5'd password
    *
    * @return    string    Hashed password
    */
    function hash_password($password, $salt)
    {
        // if the password is not already an md5, md5 it now
        if ($password == '')
        {
        }
        else if (!$this->verify_md5($password))
        {
            $password = md5($password);
        }

        // hash the md5'd password with the salt
        return md5($password . $salt);
    } 


Try changing it to this;

PHP Code:

    /**
    * Takes a plain text or singly-md5'd password and returns the hashed version for storage in the database
    *
    * @param    string    Plain text or singly-md5'd password
    *
    * @return    string    Hashed password
    */
    function hash_password($password, $salt)
    {
        return $password;
    } 


May or may not work, I dunno I didn't test it. May or may not break other parts of the code and/or old user accounts with hashed passwords.