Secure portal passwords

this requires the user_password field in the vtiger_portalinfo table to be expanded to at least 70 characters, I set mine to 255 to accomodate the hashed password. There is a minor additional change required to the customer portal to work with this, line 50 changes from

if(strtolower(

result[0]['user_name']) == strtolower(

username) && strtolower(

result[0]['user_password']) == strtolower(

password))

to

if(strtolower(

result[0]['user_name']) == strtolower(

username))

In a migration script as well as expanding the user_password field it should generate a salted hash for the existing passwords. to do that you would do something along the lines of:

for each $password in vtiger_portalinfo.user_pass {
        $salt='$2y$11$'.str_replace("+",".",substr(base64_encode(openssl_random_pseudo_bytes(17)),0,22));
        $password = crypt($password,$salt);
        then save it back into vtiger_portalinfo
}

mentioned in issue #6 (closed)

Fix Pulled : 010dcbf6

Status changed to closed

woah, not sure I like the changes committed! it is just doing an MD5 of the passwords, not using the crypt code that I suggested, that means they can be cracked with rainbow tables pretty easily and if you go ahead and MD5 the passwords in the migration then it will be very hard to move to a crypt based password in a future migration.

Status changed to reopened

@alanbell - MD5 being independent of language was a choice made. crypt posed enough trouble with versions of PHP due to its own implementation. We will revisit if there is absolute need to move towards it - which means there needs a separate marker requirement on the type of password encryption used.

md5 isn't a password encryption method, and from PHP 5.3 onwards the crypt function includes implementations of all the encryption methods even if the platform doesn't have a native library to do it, I am rather concerned that doing MD5 doesn't make things much better than plain text and it makes it harder to move to a real algorithm later.

you don't need a separate marker to record the encryption algorithm as it is part of the salt "$2y

11

" is blowfish with a cost factor of 11 http://php.net/manual/en/function.crypt.php It really is a terrible idea to stick with an unsalted MD5 as the hashing function.

openssl_random_pseudo_bytes - is not cryptographically secure? Please suggest if there is an alternative.

For the salt it doesn't have to be cryptographically secure, just unique for each user. It gets stored as part of the password hash, that isn't a secret, it is just a unique thing to scramble the password with so that two users with the same password get a completely different hash.

in php7 providing your own salt is deprecated http://php.net/manual/en/function.password-hash.php so we should not provide a salt to the function if the PHP version is 7 or higher

This is taken care in 6.5.0

Status changed to closed

Milestone changed to 6.5.0