Security Issue - Encryption and Decryption of the database text fields

[DonnaScriptTechs]

From @Mthorganby on May 15, 2017 19:20

Problem I think is with the CORE...

I think everyone is wondering about this too ......

MY QUESTION: When will this be implemented within the SE PHP software?

I am a security freak ! :p

I had a phone call from a local hospital to discuss the SE software, but after hearing worldwide security scam on the radio I was wondering about the security of the database. (Cyber-security breaches, Databases stolen, file-encrypting malware, etc) I had to put this on hold for the time being and would discuss with SE itself.

My findings:

All user data (name, email, shown user name, address, etc), all profile questions/answers, and any data stored in other fields of the modules are all stored in plain text, the activity feed data is in plain text. Also the salt is stored in the user record in plain numbers to decrypt the password. This should never be stored within the database or an external hash is used on it to encrypt the salt.

• MD5 encryption has been hacked already and is for everyone to show how it has been done. • MYCRYPT_RIJNDAEL_256 should be used as this is the latest encryption technology out there. • Password should be hashed

If someone tries to bypass the security and managed to gain access to the database. They will have everything they need to scam and spam users.

I think this is a big security vulnerability in the SE system. Every plain text field should be encrypted/decrypted in this day 'n age.

---

Here a little sample code with MCRYPT_RIJNDAEL_256 to be implemented to make it more secure:

Note: The top two lines needs a system so it is not hardcoded in the PHP nor in the same database.

Note: Password hash doesn't need to be decrypted as it is for the system use only. Passwords will be encrypted if reset and the user will have update their password. So it is only encryption.

Note: The fields in the database will have to set to VARBINARY to use the MCRYPT_RIJNDAEL_256, a script will have to be written for converting the database.

$key = md5('encryption key')
$salt = md5('encryption key')

//Encrypt
function encrypt($string, $key){
    $string = rtrim(base64_encode(mycrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $string, MCRYPT_MODE_ECB)));
}

//Decrypt
function decrypt($string, $key){
    $string = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, base64_decode($string$, MCRYPT_MODE_ECB));
}

//PasswordHash
function hasword($string, $salt){
    $string = crypt($string. '$1$' . $salt . '$');
}

Copied from original issue: SocialEngine/phpv4-issues#738

[DonnaScriptTechs]

From @RaymondBenc on May 17, 2017 8:19

Thanks for brining this to our attention. We have planned on updating our password strategy with an upcoming release and we will not be using the dated MD5 routine any longer.

[DonnaScriptTechs]

From @Mthorganby on May 17, 2017 9:13

Thanks but not only the password should be encrypted to the latest version of encryption/decryption.

It is a must to have the following is encrypted:

1. Display name first name, last name: (engine4_users -> displayname)
2. Email: (engine4_users -> email)
3. Password: (engine4_users -> password)
4. All profile questions/answers with readable text in db are also encrypted: (table engine4_user_fields_values)

The next two need also encryption as people will or may print names/ful names into the fields:

1. All modules where plain text is used
2. Activity feed

All plain text within the database should be encrypted. It will not slow the database down as PHP will encrypt it. The method MCRYPT_MODE_ECB will encrypt values in blocks. ECB works faster than CBC as CBC will wait for the output of the first encryption block to encrypt the next block.

Also the $salt and $key must have an external encryption either from a file or hidden in an external database where a encryption phrase is stored.

This will provide better security about personal information.