Extension to safely store sensitive information. Data will be encrypted and only accessible by users with the appropriate credentials. The goal of the module is to protect sensitive information both from unauthorized access from within the company and from anybody who could somehow get a hold of our full database, be them ill-intentioned or simply third parties that require access to support or solve problems.
|CI INFO No||autonumber||Identifier|
|CI Related to||relation||Accounts,Contacts|
|CI Category||picklist||— Please Select —,Access Information,Personal Information,Other Information|
|Assigned To||assigned to|
This module is related to an account/contact and an asset. You will be able to see the list of associated confidential information records in the +info tab of the related entities.
A Confidential Info record will have two parts:
This module requires the use of the MySQLi php extension, it will NOT work correctly without it.
It will not have comments support, nor import/export capabilities, among others.
Import could be easily activated but would only be useful in one situation, which is the initial import. If we import sensible information it will be imported in plain text. Once imported we could launch the initial encryption process and it would all be encrypted. After that, the import process would not work anymore as the information would (again) come in plain while the module expected it to be encrypted.
It will have an automatic history log, similar to the existing functionality in tickets or potentials.
When trying to access detail or edit view, the user will automatically be prompted for a company-wide password. If it is given correctly, access will be granted and logged. If not, access will be denied and logged.
Once access has been granted, a time countdown will start. When the time has been consumed, the browser will be redirected to the Confidential Information list view, effectively hiding the information from sight. The length of this timer can be configured in Settings.
If a record is recovered from the Recycle Bin it should still be accessible even if the company password was changed in between deleting and recovering.
Internally all the information will be saved encrypted using PHP mcrypt library. The company password will be saved using sha1 hash and the necessary information vector will be changed each time the password is changed.
In module manager administration tools for the module, you will be able to change the company password. This is a global process that will decrypt ALL the information saved in the module and encrypt them again using the new password and information vector.
Since we are using standard encryption methods and following standards, if somebody does get a hold of your database, it should take them a VERY long time (years) to retrieve the company password necessary to decrypt the stored information, but, as usual with this type of requests and work, it is just as good as the passwords you use. If you decide to use your company name for the company-wide password, then it won't take anybody to long to get access to the information
To use this module, you install it using the module manager, then create the custom fields that you need to save the sets of confidential information you have.
This module requires php_mcrypt to be enabled in your PHP configuration as this extension is used to encrypt the information.
Next, you can access the Change Password section through module manager:
Establish the company-wide password and you can start using the module as you would with any other module. The difference will be that you will be asked for the company password each time you try to access the detail or edit view. If you give it correctly you will be able to access the information, if not you will not be able to see the information.
If you lose the password you lose your information, there is nothing more to say.
Use this module at your own risk. We have not had any problems (yet), but we should not be held liable for any data loss or other events derived from the use of this module.
Alternatively to the mcrypt methods, we can also encrypt the information with the more secure libsodium library.
Here are some links on the benefits and how to install the library for it's use with PHP.
Alternatively to the mcrypt methods, we can also encrypt the information with the more secure openSSL library.
Here are some links on the benefits and how to install the library for its use with PHP.
This method expects to find both the private and public key in some directory accessible from the coreBOS install. This means that the security of this method is inexistent. PKI security is based on how secure you can keep your private key. Since we have both public and private together, in the code, anyone who gets access to your code has direct access to the information.
So, why did we implement it? Because you can use the public key to encrypt the information and not save the private key in the system. If the private key does not exist, no information will be shown. If you need to access the information you must send it to some other system where the private key lives and decrypt it there.
The module has a generalized layer for the encryption and decryption actions making it fairly easy to implement other ways of protecting your information.
If you are interested, you can contact us for help or have a look at this article that explains how that can be done.
As with most of the development we create, we try to create infrastructure, things you can use in your own developments, not just functionality. Once an encryptionmethod is configured, you can use this module to encrypt and decrypt any information anywhere in the application. For example, in after_save event or in some hook,…
This is what a small script to encrypt a couple of values looks like:
include 'vtlib/Vtiger/Module.php'; include_once 'modules/ConfidentialInfo/ConfidentialInfo.php'; $info = array('text'=>'text example','num'=>'123.456'); $encrypted = ConfidentialInfo::encryptFields_pki($info, 'file://public.key'); var_dump($encrypted); $decrypted = ConfidentialInfo::decryptFields_pki($encrypted, 'file://private.key'); var_dump($decrypted);
Future options to consider in design (not in scope yet)
resume password change. If the password change is interrupted information will be lost, this must be fixed. The solution is to save the previous decrypt information until the whole process is done and mark each record as processed as they are changed. This way we can continue on non-processed records if something goes wrong without losing information.
If anybody wants to sponsor this contact me
With the help and support of Object Solutions, Thanks!!