XOOPS 2.5 - Password Security Patch
Community Release by Chronolabs Co-op

You may have heard about this when the linked-in user database was hacked that anonymous where reverse engineering over 2.4 million passwords as they where stored in a none reversible none symposium checksum which meant through a dictionary attack, you could by comparing the checksum to a test case, work out someone password, this is typically possible with ALL NONE REVERSIBLE CHECKSUMS.

Many months ago I worked on a checksum/hash called QCP the Quantum checksum process at lengths of around 12 or less it becomes a symposium checksum that is has collisions with other variants of data that share a similar fingerprint. This means there are many possible data types or password that could have the same checksum. But of course if you lengthen the fingerprint to 28 or more in length there is no possible collision point for the fingerprint.

In this package there is a variation of QCP I have written called XoopsCRC, which provides hash which is bitwise comparable. And a secondary class loader for a shorter version of it which is simply a hash called password. There is also a modified /kernel/members.php which allow for a comparison of both md5 and password fingerprints so any user that hasn't reset there password since the patch is applied can still log in. Also something when you forget your username you can also use an email address to log in instead of a username. This is the XoopsMembersHandler::loginUser() function.

I have also removed the use of md5 for new accounts in both the core files as well as the profile module which is included in the patch.. This is simply done by replacing md5() with XoopsHash::password().

Download: xoops2.5_password_security_1.0.1.zip - 30Kb

readme.txt

[size=xx-small]-----------------------------------------------------------------------------------------------------------
-[ XOOPS Password Security Patch for XOOPS 2.5 08-09-2012 14:21 - For XOOPS 2.5.x ]-----------[ v 1.0.1 ]--
-----------------------------------------------------------------------------------------------------------
- :: Preword :: -
- -
- Currently with the current distribution of XOOPS the user passwords are stored in an md5. This means if -
- a hacker was able to get a copy of your user table in mysql, he would be able to reverse engineer the -
- md5 with a dictionary attack or md5 reverser to find out your users password. If the user has a common -
- password on system it would then allow him to be exposed on the internet to fraud, deception and -
- general unpleasantness. -
- -
- The checksum used in XoopsHash::password() function is a symposium checksum which means there is many -
- possible results for the password in the scope for data. this means there is no way of reversing the -
- checksum that has collisions with other data combinations of varied lengths so there passwords are -
- secure from reverse engineering and dictionary attacks. -
- -
- :: Installation :: -
- -
- Copy the content of the /htdocs folder in the zip over the top and replacing the files in XOOPS 2.5 -
- the /htdocs folder contents is copied into your public root path the same path as the define in -
- mainfile.php called XOOPS_ROOT_PATH. This is typically on unix system the folder called public_html. -
- -
--[ simon@chronolabs.com.au ]-----------------------------------------------------------[ @itswishcraft ]--[/size]

changelog.txt
[size=xx-small]----------------------------------------------------------------------------------------------------------
- XOOPS Password Security Patch for XOOPS 2.5 08-09-2012 14:21 - For XOOPS 2.5.x -
----------------------------------------------------------------------------------------------------------
* changed /kernel/member.php XoopsMemberHandler::loginUser old md5() as well as XoopsHash::password()
* changed /lostpass.php XoopsHash::password() implemented instead of md5()
* changed /register.php XoopsHash::password() implemented instead of md5()
* changed /modules/profile/lostpass.php XoopsHash::password() implemented instead of md5()
* changed /modules/profile/register.php XoopsHash::password() implemented instead of md5()
* added /class/hash/xoopshash.php Xoops Checksum Handler
* added /class/hash/md5/md5.php Md5 Checksum Handler
* added /class/hash/sha1/sha1.php Sha1 Checksum Handler
* added /class/hash/xoopscrc/xoopscrc.php Xoops CRC Checksum Handler
* added /class/hash/xoopscrc/xoops.crc.base.php Xoops CRC Base Class
* added /class/hash/xoopscrc/xoops.crc.class.php Xoops CRC Handler Class
* added /class/hash/xoopscrc/xoops.crc.enumerator.php Xoops CRC Enumerator Class
* added /class/hash/xoopscrc/xoops.crc.leaver.php Xoops CRC Leaver Class
* added /class/hash/password/password.php Xoops Password Checksum Handler
----------------------------------------------------------------------------------------------------------[/size]

This issue with md5 is a very old issue that has been discussed frequently here and there.
eg:
https://xoops.org/modules/newbb/viewtopic.php?post_id=243447#forumpost243447

IMO Dave_L suugestion is perfect even after 6 years:
Quote:

IMO with the above implementation there is no need to change all md5() with XoopsHash::password()

Let me just go into the XOOPSCRC or QCP checksum for you breifly. The checksum is based in one of the oldest fractal systems on the planet called the i-ching. It has a complexity wrapper around it and is bitwise so it has 2 planes.

Firstly to work out the base of the checksum, in a single seed there is 62/63 characters or nodes, with either 1 or two wild cards, which are replaced by digitals 0 - 9 when they occur. So saying there is two wildcards or aa/AA in a base for the enumeration you would do the following maths to work out the base of the algorithm.

Base of algorithm variant 1 = 62 x 2 + 10 = base 134
Base of algorithm variant 2 = 63 x 2 + 10 = base 136

Why 64 well the i-ching is 64bit having 64 different binary combinations in it, consisting of 6 binary components or elements per character being parsed. To work out if you have any collisions you multiple the number of characters your outputing by the number of nodes per character which is 6. But remember there is a nuclear process in each node which has a combination of 4 so the number of combinations in the i-ching is 6 * 10 ^ 2. Why the power to function of 2 well the nuclear process in this formula is broken down and also has a XOR cipher function in it as well. Now because of this ciper function in the base of it, you also have to put this to the power of 2 to power of 2 due to the bit wise so the actual base of the algorithm is:

Base of algorithm variant 1 = (62 x 2 + 10) ^ 2 ^ 2 = base 322417936
Base of algorithm variant 2 = (63 x 2 + 10) ^ 2 ^ 2 = base 342102016

This means no collisions occur in the formula as the square root of the base divided by 10 divided by 64 divided by 2

No collisions at square root((62 x 2 + 10) ^ 2 ^ 2) / 10 / 64 = 28.05625 or with variant 2 square root((63 x 2 + 10) ^ 2 ^ 2) / 10 / 64 = 28.9 these variables are floored coming to 28 in total for no collision point, anything less than 28 has more collisions which you can work out in a percentile so for example of 100% of data types 12/28*100 = 42.857142857142857142857142857143 meaning that of 100% of data there is a chance of odds of 42.9% that a reoccurring fingerprint will occur.

that no collision formula is based on a none bitwise algorithm you would have to divide by 2 again for QCP/XoopsCRC to come up with no collisions at around 14 characters.

Quote:

In fact the use of a salt is not correct, you need a checksum with collisions in it, all none reversible checksum including sha-256 or md5 with a salt added does not adequately protect you, it is still comparable and this solution is not valid.. If they have your user table then they have your PHP and looking up the salt to see what they need to add to the dictionary attack is a piece of cake. Infact most dictionary attacking software titles allow you to add a prefix or postfix to the comparative functions.

The solution you have offered here like the md5 or sha-256 which have no collision points as a checksum, you might as well store it in open text reguardles of whether this twit that has offered this as a solution is obviously not the brightest thinker if he thinks there is any difference between md5($pass) or md5($salt.$pass) or sha-256($pass) or sha-256($salt.$pass) there is no collision or symaltyping of data.

I would like to also refer you to this recent tweet conversation:

* https://twitter.com/SysReboot/status/244167777546559488

* https://twitter.com/itswishcraft/status/243898755873644545

lol..

Quote:
[Edited by Mamba]
if you think that software storing passwords in none reversible formulas with no collisions is something of a solution, you're wrong.
[/Edited by Mamba]

So we are talking about passwords, so on average there would be 52 characters plus 10 numbers so there would be around 62 characters of a 256 character ascii table. So to work out the actual collision point you would need or have you would use the following formula ((12/28)/28) / ((62/256)/256) = 16.179065174456879526003949967084 which means around 16% of passwords will have colliding checksums which is fine for a password as you are using a username, email address, biometric data as a comparative point against the data anyway.

This of course if you are including password length of minimal length of 5 and a maximum length of 15 you would do the following formula(((8/14)/14)*((5/15)/1)) / ((62/256)/256) = 14.381391266183892912003511081852 which means that only 14% of password would have collisions based in length of 5 – 15 characters in a password of 62 characters.

Simon, you really shouldn't be calling people names if they don't 100% think your solutions are the best solutions right up front.

And really, do we really care?

This stuff is inaccessible unless someone hacks into your database.

Sure, under the current MD5 someone could produce a program that could come up with passwords that fit the saved data but it can be time consuming and the person would need at a minimum a printout of the encrypted passwords.

And yes a Salt could work fine because unless the hacker knows some of the passwords and can reverse engineer the salt they are not going to be able to reverse engineer the passwords or guess the salt.

So if they were able to have 2+ accounts on the server where they used specific passwords they could likely reverse engineer the salt but the more levels you add the harder it becomes.

The steps that would need to be taken to bypass this security would be similar to steps that could be used to bypass this "urgent patch". If someone has the access to the database required to gain access to these passwords the system can be manipulated easily. So realistically it doesn't matter if you saved the passwords as straight text. A potential hacker still has to access the database and get the password lists.