Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke
Author Message
testy1
Involved
Involved


Joined: Apr 06, 2008
Posts: 484

PostPosted: Tue Jul 01, 2008 11:59 pm Reply with quote

im just wondering, should we be using sha1 instead of md5, is it possible.

e.g.

Code:


define('SALT', 9);

function SuperEncrypt($plainText, $salt = null)
{
    if ($salt === null)
    {
        $salt = substr(md5(uniqid(rand(), true)), 0, SALT);
    }
    else
    {
        $salt = substr($salt, 0, SALT);
    }

    return $salt . sha1($salt . $plainText);
}

$pwd = SuperEncrypt(sha1($pwd));


is this pointless, or am i missing something, i understand that they maybe able to exploit the site through other methods but if tghey did happen to get your database, they wouldn't be able to crack any passwords?

and i read somewhere that sha1 has been available since php 4.3 or there abouts
 
View user's profile Send private message
evaders99
Former Moderator in Good Standing


Joined: Apr 30, 2004
Posts: 3221

PostPosted: Wed Jul 02, 2008 12:02 am Reply with quote

Probably, but phpBB 2 uses md5 right now. phpBB3 introduces their own hashing which may be better

_________________
- Only registered users can see links on this board! Get registered or login! -

Need help? Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
testy1
PostPosted: Wed Jul 02, 2008 12:06 am Reply with quote

would it be that difficult to change?
 
montego
Site Admin


Joined: Aug 29, 2004
Posts: 9449
Location: Arizona

PostPosted: Wed Jul 02, 2008 6:17 am Reply with quote

testy1 wrote:
would it be that difficult to change?


The concern I would have is you have no way of converting any existing users over... You would have to figure out how to use both. I am just saying that it might not be as straightforward as you may think.

_________________
Only registered users can see links on this board! Get registered or login!
Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
evaders99
PostPosted: Wed Jul 02, 2008 8:42 am Reply with quote

Right, an existing user database cannot be converted. You'd have to get everyone to create a new account or some authentication to change their password to be re-encrypted
 
testy1
PostPosted: Wed Jul 02, 2008 4:00 pm Reply with quote

also i was reading about it yesterday and it was saying how the chances of 2 passwords having the same hash is extremely remote, so with this said how do you check the hash against what you have enetered.

for the current user passwords i suppose you could recreate new passwords and have nuke send them out......

just thinking out loud really.
 
Guardian2003
Site Admin


Joined: Aug 28, 2003
Posts: 6792
Location: Ha Noi, Viet Nam

PostPosted: Wed Jul 02, 2008 4:47 pm Reply with quote

If I remember the 'flaw' in the encryption routine (MD5) correctly; for two users to have the same hash would require both users to use the same identical password and both submissions be processed at exactly the same time by the server. As instructions are processed concurrently, the chances of all these variables aligning at the same 'instant' would be mathematically, so extremely remote it isn't even worth trying to calculate it.
SHA-1 also uses a similar process to MD5.
In order to further make each calculation different a salt is used.

It might not be possible to get nuke to reprocess the passwords as they are stored quite specifically in an MD5 database field to ensure they are never 'human readable'.
In theory, assuming you have reworked all the files to use SHA-1 you could possibly write a routine to to do a mass reset of all passwords to a known password (or password pattern like username+userid) and get them all to revalidate their accounts after switching the DB field to SHA-1 (if it is possible).

To be honest, it is way more trouble than it's worth and it would be simpler and more effective to just do a double MD5 routiine (MD5 encrypting the MD5 hash).
 
View user's profile Send private message Send e-mail
testy1
PostPosted: Wed Jul 02, 2008 6:03 pm Reply with quote

ok so for e.g.

Code:


$pwd = md5(md5(($pwd));


so would this making it harder to crack.....

and for the 2 passwords the same i was basically trying to say that most admins will use the same password for both there accounts and once they get say a suspected admins user hash they will search for the same hash to identify there admin account

ok so in a dream worl lets say we implement sha-2 (SHA-512/384) and everything works perfectly, what have we acheived, have we made the system anymore secure or have we made it harder to recover the admin and users password but still hasn't effected the over all ability for someone to breach your cms.

EDIT

a little test actually shows they dont seem to change

Code:


$password = 'my_super_duper_password_wears_a_pink_bikini';
echo '<br /><br /><br />';
printf("<strong>Original password:</strong> %s\n", $password);
echo '<br /><br />';
printf("<strong>MD5 hash:</strong> %s\n", md5($password));
echo '<br />';
printf("<strong>SHA-1 hash:</strong> %s\n", sha1($password));
echo '<br /><br />';
// or for php5+
printf("<strong>SHA-512 hash:</strong> %s\n", hash('sha512', '$password'));
 
testy1
PostPosted: Wed Jul 02, 2008 7:15 pm Reply with quote

Just as a quick test i added the following function to mainfile.

Code:


function SuperEncrypt($pwd) {
   return sha1(sha1($pwd));
   }


and then changed both instances of md5 in admin file to

Code:


$pwd = SuperEncrypt($pwd);


i then created a new admin account by browsing to the admin file and everything seem to work perfectly.

EDIT

lol this also worked perfectly but stored it a little obscured

this is a working e.g. of the SHA-2 implementation.

Code:


function SuperEncrypt($pwd) {
   return hash( 'sha256', $pwd, true );
   }


and stored this in the database

Code:


¶Ž©B,Mi†±¼Îô=7•€Á˜æ´Ç`g©
 
evaders99
PostPosted: Wed Jul 02, 2008 8:25 pm Reply with quote

Of course the hash is just a long number. You will need to use a base64 encoding scheme to turn it into normal ASCII character.

Double encryption could help, it just adds another layer. The hash is one-way but it has a finite number of combinations - thus "cracking" is really just brute forcing it. There are many sites that store rainbow tables used to manually go through all kinds of password combinations until a hash is matched.
 
testy1
PostPosted: Wed Jul 02, 2008 8:49 pm Reply with quote

what if the password field was set to binary, or am i an idiot?

and would all this be just a waste of time, or is it keeping up with the times
 
Gremmie
Former Moderator in Good Standing


Joined: Apr 06, 2006
Posts: 2415
Location: Iowa, USA

PostPosted: Wed Jul 02, 2008 9:08 pm Reply with quote

The only thing that is really wrong with the current Nuke scheme is the lack of a salt. It is good enough for most purposes. If I was doing a new CMS or new Your_Account, and didn't have to worry about phpBB integration, I might use sha1 or something newer (with a salt).

_________________
Only registered users can see links on this board! Get registered or login! - An Event Calendar for PHP-Nuke
Only registered users can see links on this board! Get registered or login! - A Google Maps Nuke Module 
View user's profile Send private message
testy1
PostPosted: Wed Jul 02, 2008 9:29 pm Reply with quote

i am extremely interested in this now, and if the occasion arrises that sha1 is to be used i would love to help out.

I may even just play around on my own Smile
 
testy1
PostPosted: Tue Jul 15, 2008 8:16 pm Reply with quote

ok i got excited again and made the following changes, this seems to work great on the latest version of RN


so far i have come up with this, it basically checks your version of php and if it supports hash it uses SHA256 otherwise it encrypts the uses password using sha1 multiple times.I also had to change the password fields in the database to accomodate the larger hash's


It seems to be working alright the only things i need to do is
* Find away to upgrade existing database passwords
* verify what version hash became available for the mainfile function and also verify what php versions support sha1

Code:



Ok lets put on our purple jumpsuits and get the party started.


Database:


 ALTER TABLE `nuke_authors` CHANGE `pwd` `pwd` VARCHAR( 65 );
 ALTER TABLE `nuke_users` CHANGE `user_password` `user_password` VARCHAR( 65 );
 ALTER TABLE `nuke_users_temp` CHANGE `user_password` `user_password` VARCHAR( 65 );



Open: admin/modules/authors.php

Find:


$chng_pwd = md5($chng_pwd);


Change To:

$chng_pwd = SUPEREnc($chng_pwd);


Open: includes/usercp_register.php

Find:

if ( $row['user_password'] != md5($cur_password) )


Change To:

if ( $row['user_password'] != SUPEREnc($cur_password) )


Find:

$new_password = md5($new_password);


Change To:

$new_password = SUPEREnc($new_password);


Find:

if ( $row['user_password'] != md5($cur_password) )


Change To:

if ( $row['user_password'] != SUPEREnc($cur_password) )




Open: includes/usercp_sendpasswd.php

Find:

SET user_newpasswd = '" . md5($user_password) . "', user_actkey = '$user_actkey' 


Change To:

SET user_newpasswd = '" . SUPEREnc($user_password) . "', user_actkey = '$user_actkey' 




Open: modules/Forums/admin/admin_users.php

Find:

$password = md5($password);


Change To:

$password = SUPEREnc($password);




Open: modules/Forums/login.php

Find:

if( md5($password) == $row['user_password'] && $row['user_active'] )


Change To:

if( SUPEREnc($password) == $row['user_password'] && $row['user_active'] )




Open: modules/Your_Account/admin/index.php

Find:

$cpass = SUPEREnc($chng_pass);


Change To:

$cpass = md5($chng_pass);



Find:

$add_pass = md5($add_pass);


Change To:

$add_pass = SUPEREnc($add_pass);




Open: modules/Your_Account/index.php

Find:

$new_password = md5($user_password);


Change To:

$new_password = SUPEREnc($user_password);



Find:

$cryptpass = md5($newpass);


Change To:

$cryptpass = SUPEREnc($newpass);



Find:

$new_pass = md5($user_password);


Change To:

$new_pass = SUPEREnc($user_password);



Find:

$user_password = md5($user_password);


Change To:

$user_password = SUPEREnc($user_password);



Open: admin.php

Find:

$pwd = md5($pwd);


Change To:

$pwd = SUPEREnc($pwd);



Find:

$pwd = md5($pwd);


Change To:

$pwd = SUPEREnc($pwd);



Open: mainfile.php

Find:

/*****[BEGIN]******************************************
 [ Base:    GFX Code                           v1.0.0 ]
 ******************************************************/


Before Add:

// Super Encrypt Method   START
function SUPEREnc($pass) {
global $phpver;
if ($phpver <= '5.1.1') {
  return sha1(sha1(sha1(sha1($pass))));
} elseif ($phpver >= '5.1.2') {
  return hash( 'sha256', $pass, false );
  }
}
// Super Encrypt Method   END

 
Gremmie
PostPosted: Tue Jul 15, 2008 8:30 pm Reply with quote

I'm not a cryptology expert, nor do I play one on TV, but I don't think you are buying anything by hashing multiple times like that.

The current nuke scheme is not salted. So two users who use the same plaintext password will get the same hash value. Try it and see. I think it would be far better to modify Nuke to add a salt than double or triple hash or even use a different algorithm. Okay, for extra credit, use a salt and sha1 (instead of md5). We have that in our to-do list, but not sure when/if we want to tackle it.
 
Guardian2003
PostPosted: Wed Jul 16, 2008 2:07 am Reply with quote

Possibly use $sitekey (config.php) for the salt?
 
testy1
PostPosted: Wed Jul 16, 2008 4:59 am Reply with quote

ok so maybe like this

Code:


function SUPEREnc($pass, $salt=NULL)
    {
      global $sitekey, $phpver;
        $salt_key = $sitekey;
       
        if ($phpver >= '5.1.2')
        {
            $superhash = hash('sha256', $salt.$pass, false);
        }
        else
        {
            $superhash = sha1($salt.$pass);
        }
        return $salt.$superhash;
    }
 
Gremmie
PostPosted: Wed Jul 16, 2008 6:50 am Reply with quote

That's better, but it is commonly recommended to use a salt based upon the current time or a short random string. You then have to store the salt in the database in order to verify logins. Check out the book PHP Pro Security for some more ideas.
 
testy1
PostPosted: Wed Jul 16, 2008 6:10 pm Reply with quote

i actually thought about that, and came up with the solution that i could use the users registration date but i thought that it woulb be useless for new rego's as they dont have a registration date yet?

or maybe you would have a custom field like a secret question so when they sign up that is used, or you could just use the current time like you said which maybe the better way to go.What do you think?
 
Gremmie
PostPosted: Wed Jul 16, 2008 8:41 pm Reply with quote

I'll have to dig out that book again. They have a few examples in there. I believe they just got the current time and used that for a salt.
 
Lucifix
Regular
Regular


Joined: Mar 11, 2005
Posts: 67

PostPosted: Fri Feb 25, 2011 12:48 am Reply with quote

To reopen this topic again...

I understand that it's almost impossible to reset all users password in users table and convert them to salted. But at least authors table could use salted password since there are usually only few admins.
 
View user's profile Send private message
Palbin
Site Admin


Joined: Mar 30, 2006
Posts: 2583
Location: Pittsburgh, Pennsylvania

PostPosted: Fri Feb 25, 2011 5:04 pm Reply with quote

I might take this up in the near future, but no guarantees.

_________________
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan. 
View user's profile Send private message
Guardian2003
PostPosted: Fri Feb 25, 2011 8:16 pm Reply with quote

Why not just hash the (admin) usernames?
Even if a successful XSS attack exposed the admins md5 hashed username, it would be just as worthless as the password because you wouldn't be able to inject it back in without decoding it - unless you could hijack the session.
At least for brute-forcing you need a bigger step up. Instead of just
password (n)tries
you would need to do
username(n)tries X password(n)tries
 
montego
PostPosted: Sun Feb 27, 2011 11:29 am Reply with quote

However, I suspect user names to be more likely something somewhat easy to remember, which would also mean them to be very likely findable in a hash database.

In addition, one would have to find everywhere within *nuke the admin user name is being displayed... Wink
 
duck
Involved
Involved


Joined: Jul 03, 2006
Posts: 273

PostPosted: Sun Mar 20, 2011 12:25 pm Reply with quote

I actually have just successfully finished updating my Nuke system to use any hash method I would like because I was victim to the single md5 getting rainbow tabled and passwords compromised.

As such I have built a new system which obfuscates the password first with a custom scrambling routine that mixes seperate salts for each the users, admins, and sentinel passwords and encodes a number of times. After that I then hash the password a number of times with whatever encryption scheme I choose like sha1 or whirlpool etc. I have the following variables added to my config file which allow me to set the numbers I want and believe it or not it doesn't take long to run an md5 1000 times on a password.
Code:


$er = 2    //The Number of times a word is encoded should not be higher than 10 but is better in mid to lower range and should not be 0
$wsr = 5    // The Number of runs the main function will run must be only 1 (cannot be 0) if er > 4
$r1 = 2   // the first random number generated at install that determines the number of spaces a letter will move cannot = $r2
$r2 = 4   // the second random number generated at install that determines the number of spaces a letter will move cannot = $r1
$rr = 10  // Number of Runs total the Word Scrambler function will run minimum must run once there is no max but will be rand 1 - 10 when install
$hashalgorythm = "whirlpool" // Supports wide range
$cryptcipher = "MCRYPT_RIJNDAEL_256"; //  Supports wide range
$hashruns = 1000
$adminsalt = "KsdgM@d%lkOl-FxP"; //salts are split in half then scrambled into password.
$usersalt = "adlrhSJsdjiS%%3"
$sentinelsalt = "aJaKPfhJA@ncm%-+"


Anyway I have it so whenever I want I can force a password change on a user and email them a new temp password. Once I a user changes a password (either because I have forced them to or they do it on their own) I store the old password in a table along with a hash id whereby I store all old hashing mechanisms so I can recompare new pwd's with old ones to ensure users don't change their passwords back to old ones. Also in this store table I store plain passwords which I do not allow users to use like "password, 123, abc" etc so I can build a list of unacceptable passwords if I like.

Cyurrently the system is 3/4 of the way complete. I have it so the Admin and Users if I manually add a new pwd (hashed of course) to the appropriate table (ie authors or users) and then add that users to a table I use for tracking changed pwds the user (or admin) is logged out and forced to a password change pange where they must enter their new temp password along with a new password of their own. Old passwords are stored along with username so that only that user is penalized for using the same password but not another user. ie if user 1 used the password "mypass" and then changes it he can never change back to "mypass" however user 2 can still use "mypass" as a password as long as I have not added it to the globally banned password list.

To keep track of all the hashes to compare as I say I use a hash tracking table.

So it would look like so

Hash Type table
field names: hash_id, algorythm, runs (of course my table includes other options for obfusecation but I am just showing the hash part).

Old Password Store Table
field names: username, password, hashid

so for most flavours of nuke
record one of hash table would be:
1, md5, 1

Now if I store a users old password with a new algorythm I am currently using to encrypt passwords (with options set in my config file) I store it with a hashid of -1 and if the password is a globally disallowed password the user is "ALL" and the hashid is 0. Of course I can use another hashid and still use ALL to globally disallow a password but where possible I prefer the password plain for global disallows to avoid taxing the sytem.

Anyway it works fantastic so far the only thing left which I am still building is the admin interface so I fo course I can manage the resets automatically. When it iis complete I will be happy to share the code publicly for inclusion into other sytems.

here is photo of the admin interface I am working on:

Image
 
View user's profile Send private message
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©