md5 | sha1

testy1 · Involved Joined: Apr 06, 2008 Posts: 483

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

evaders99 · Posted: Wed Jul 02, 2008 12:02 am

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

testy1 · Involved Joined: Apr 06, 2008 Posts: 483

would it be that difficult to change?

montego · Posted: Wed Jul 02, 2008 6:17 am

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.

evaders99 · Posted: Wed Jul 02, 2008 8:42 am

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 · Involved Joined: Apr 06, 2008 Posts: 483

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 · Posted: Wed Jul 02, 2008 4:47 pm

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).

testy1 · Involved Joined: Apr 06, 2008 Posts: 483

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 ' ';
printf("Original password: %s\n", $password);
echo ' ';
printf("MD5 hash: %s\n", md5($password));
echo ' ';
printf("SHA-1 hash: %s\n", sha1($password));
echo ' ';
// or for php5+
printf("SHA-512 hash: %s\n", hash('sha512', '$password'));

testy1 · Involved Joined: Apr 06, 2008 Posts: 483

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 · Posted: Wed Jul 02, 2008 8:25 pm

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 · Involved Joined: Apr 06, 2008 Posts: 483

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 · Posted: Wed Jul 02, 2008 9:08 pm

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).

testy1 · Involved Joined: Apr 06, 2008 Posts: 483

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 · Involved Joined: Apr 06, 2008 Posts: 483

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 · Posted: Tue Jul 15, 2008 8:30 pm

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 · Posted: Wed Jul 16, 2008 2:07 am

Possibly use $sitekey (config.php) for the salt?

testy1 · Involved Joined: Apr 06, 2008 Posts: 483

ok so maybe like this

Code:

Gremmie · Posted: Wed Jul 16, 2008 6:50 am

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 · Involved Joined: Apr 06, 2008 Posts: 483

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 · Posted: Wed Jul 16, 2008 8:41 pm

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 Joined: Mar 11, 2005 Posts: 62

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.

Palbin · Posted: Fri Feb 25, 2011 5:04 pm

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

Guardian2003 · Posted: Fri Feb 25, 2011 8:16 pm

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 · Posted: Sun Feb 27, 2011 11:29 am

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 Joined: Jul 03, 2006 Posts: 267

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: