advcomputer
Posts: 68
|
| Posted: 05/13/2015, 8:51 AM |
|
Is Code Charge going to address this issue?
http://www.darkreading.com/vulnerabilities---threats/ph.../d/d-id/1320353
PHP Hash Comparison Weakness A Threat To Websites, Researcher Says
Flaw could allow attackers to compromise user accounts, WhiteHat Security's Robert Hansen -- aka "RSnake" -- says in new finding on 'Magic Hash' vulnerability.
A weakness in the manner in which PHP handles hashed strings in certain situations gives attackers an opportunity to try and compromise authentication systems, passwords, and other functions involving hash comparisons in PHP, a researcher from WhiteHat Security says.
Robert Hansen, vice president of WhiteHat, describes the issue as one that affects any website that uses two specific types of operators for comparing hashes in PHP.
The issue mostly affects authentication, but it could also effect "forgot password" flows, nonces, binary checking, cookies, and passwords, among other things, Hansen, aka RSnake, told Dark Reading. "It totally depends on the website, and how it's constructed."
SPONSOR VIDEO, MOUSEOVER FOR SOUND
The problem exists in the manner in which PHP handles hashed strings when either the double equal (==) or "!=" operators are used to compare them. When either of these two operators is used for comparing hashes, PHP interprets any hashed value beginning with 0e as having the value 0.
So if two different passwords are hashed and both their hashed values begin with 0e followed by numerals, PHP will interpret both as having the value 0. Even though the hash values for both passwords are completely different, PHP would treat them both as the number zero if both begin with 0e and when either == or != are used.
Think of "0e..." as being the scientific notation for "0 to the power of some value" and that is always "0", Hansen noted in a blog post Friday. PHP interprets the string as an Integer.
The implications are huge because it gives attackers a way to try and compromise user accounts by entering a string that when hashed gets equated to zero by PHP. If a password in the database is represented the same way, the attacker will get access to the account, Hansen said.
The problem itself has been known for at least a year, Hansen said. But what hasnt been available are examples of hash types that when hashed begin with the 0e format that ends up getting equated to zero, he said.
In a blog, Hansen listed several "magic" numbers that he found could be used as passwords, which when hashed, end up being treated as 0 by PHP.
When such hashes are compared against the hashes of actual password, values that are also treated as 0 by PHP they end up getting evaluated as being equivalent, or true. In such cases attackers will be able to log into the account without the valid password, he said.
To find the strings, Hansen iterated over 1 billion hashed integers of different hash types like MD5 and SHA1. Though the technique was inefficient it was reasonably effective at finding strings that triggered the weakness for most hash algorithms with a length of 32 characters or less, Hansen said in his blog.
Hansen said he estimated the chances of a 32-character hash triggering the issue was somewhere in the range of 1 in 200 million. While that might seem like an extremely low probability, it is often enough for attackers to want to try and trigger the flaw especially on a high volume website or one with a lot of credentials.
Addressing the problem is very simple, he said. Websites using PHP should analyze their code for hash comparisons in PHP using == or != and change them to === or !== respectively, he said.
Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio
|
 |
 |
eratech
Posts: 513
|
| Posted: 05/13/2015, 11:41 PM |
|
My interest is in decent password hashing and verification and while I'm pleased with CCS and it's productivity boost for me, the default password hashing and examples (MD5!) annoy me.
MD5 and SHA1 shouldn't be used for passwords for a number of reasons beyond the above 'vulnerability' (pre-generated lists allow lookups without brute forcing; non-salted hashes will allow same passwords result in same hashes; very quick to hash makes brute forcing millions of passwords much easier)
More info: http://php.net/manual/en/faq.passwords.php
and PHP 5.5+ has some built-in functions to make it easier: http://php.net/manual/en/ref.password.php
While I know nothing about CCS future plans, I suspect we will need to improve it ourselves.
Another reason for me to get off my buttocks and do something about it. Dammit! 
Eric
_________________
CCS 3/4/5 ASP Classic, VB.NET, PHP
Melbourne, Victoria, Australia |
|
|
|
MichaelMcDonald
Posts: 640
|
| Posted: 05/14/2015, 6:18 AM |
|
I am trying the use of multiple encryption using CCEncryptString on top of MD5. It works, but not being a security expert I am not sure on the implications. I am keen to hear what you think about this.
This is part of Button_DoLogin (index.php):
global $CCSLocales;
global $Redirect;
if ( !CCLoginUser( $Container->login1->Value, (md5($Container->password->Value)))) {
$Container->Errors->addError($CCSLocales->GetText("CCS_LoginError"));
$Container->password->SetValue("");
$Login_Button_DoLogin_OnClick = 0;
} else {
This is common.php:
function CCLoginUser($login, $password)
{
CCLogoutUser();
$key1 = ")8HztMNKz]fB-}Vg_dH`'ahTA?U]rc92G*-%qz6/U^5`@{)-qZX/hxbfgJ#qW42%}:}S8x'CC<6f4]?yq";
$key2 = "j+9dXyvszSNar_9%!p-ZD7A#4fgZaeWvs^KgMmKnAM2C?Ux^?ayyU9Yae!6@6@eM";
$key3 = "@-GQJ!S?+8xDMXvtM2u*62nYzEMH=CA*n4LrR9^tt8#vyb@yz3^HJeSVP4+GZXPP";
$password = CCEncryptString($password, $key1);
$password = CCEncryptString($password, $key2);
$password = CCEncryptString($password, $key3);
$db = new clsDBConnection1();
$SQL = "SELECT iduser, groupid, password, firstname, lastname FROM user WHERE email=" . $db->ToSQL($login, ccsText) . " AND password=" . $db->ToSQL($password, ccsText);
$db->query($SQL);
$Result = $db->next_record();
if ($Result) {
CCSetSession("UserID", $db->f("iduser"));
CCSetSession("UserLogin", $login);
CCSetSession("firstname", $firstname);
CCSetSession("lastname", $lastname);
CCSetSession("GroupID", $db->f("groupid"));
CCSetSession("UserAddr", $_SERVER["REMOTE_ADDR"]);
}
return $Result;
}
//End CCLoginUser
On the password form:
This is my password onvalidate (I move the encypted password into a session variable) and change the password as part of the Update Button on click...
On Validate
$currentpass = $changepassword->currentpass->GetValue();
$newpass = $changepassword->newpass->GetValue();
$confirmpass = $changepassword->confirmpass->GetValue();
$db = new clsDBConnection1();
$SQL = "SELECT password FROM user WHERE iduser=". CCGetSession("UserID",ccsInteger);
$db->query($SQL);
if($db->next_record()){
$oldpd = $db->f("password");
}
$currentpass = (md5($currentpass));
$key1 = ")8HztMNKz]fB-}Vg_dH`'ahTA?U]rc92G*-%qz6/U^5`@{)-qZX/hxbfgJ#qW42%}:}S8x'CC<6f4]?yq";
$key2 = "j+9dXyvszSNar_9%!p-ZD7A#4fgZaeWvs^KgMmKnAM2C?Ux^?ayyU9Yae!6@6@eM";
$key3 = "@-GQJ!S?+8xDMXvtM2u*62nYzEMH=CA*n4LrR9^tt8#vyb@yz3^HJeSVP4+GZXPP";
$currentpass = CCEncryptString($currentpass, $key1);
$currentpass = CCEncryptString($currentpass, $key2);
$currentpass = CCEncryptString($currentpass, $key3);
if($currentpass !== $oldpd){
$changepassword->Errors->addError("Current Password cannot be verified.");
}
if ($newpass == NULL){
$changepassword->Errors->addError("New Password is required.");
}
if ($confirmpass == NULL){
$changepassword->Errors->addError("Confirm New Password is required.");
}
if(CCStrLen($newpass) && !preg_match("/^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{10,}$/", $newpass)){
$changepassword->Errors->addError("Password must be 10 characters containing at least 1 UPPERCASE, 1 lowercase, 1 digit and 1 special character.");
}
$newpd = (md5($newpass));
$newpd = CCEncryptString($newpd, $key1);
$newpd = CCEncryptString($newpd, $key2);
$newpd = CCEncryptString($newpd, $key3);
if($currentpass == $newpd){
$changepassword->Errors->addError("Cannot re-use current password.");
}
$SQL = "SELECT pd FROM prevpd WHERE pd = '$newpd' AND userid=" . CCGetSession("UserID",ccsInteger);
$db->query($SQL);
if($db->next_record()){
$pd = $db->f("pd");
}
if($pd !== NULL){
$changepassword->Errors->addError("Cannot use a previous password.");
}
if($pd == NULL){
if($confirmpass !== $newpass){
$changepassword->Errors->addError("Passwords Did Not Match.");
}
}
$db->close();
if($currentpass !== NULL and $confirmpass !== NULL and $newpass !== NULL and $currentpass == $oldpd and $newpass == $confirmpass and $pd < 1){
CCSetSession("pword", $newpd);
}
Now change the password using the Button Update on click event:
(As part of this I also select the current password and move into the prevpd table which gets used in the above mentioned on validate event. ($oldpd)...
On Click
CCSetSession("chgpwd","0");
$pword = CCGetSession("pword");
$db = new clsDBConnection1();
$now = TIME();
$SQL = "SELECT password FROM user WHERE iduser=". CCGetSession("UserID",ccsInteger);
$db->query($SQL);
if($db->next_record()){
$pd = $db->f("password");
}
$userid = CCGetSession("UserID",ccsInteger);
$SQL = "INSERT into prevpd(pd, userid, chgtimestamp) VALUES ('$pd', '$userid', '$now')";
$db->query($SQL);
$SQL = "UPDATE user SET password = '$pword'" .",". "chgpwdtimestamp = '$now'" .",". "firstlogin = '0'" . "WHERE iduser=". CCGetSession("UserID",ccsInteger);
$db->query($SQL);
$db->close();
CCSetSession("pword","");
_________________
Central Coast, NSW, Australia.
|
|
|
|
|
