Securing (encrypting) a custom field?

[color=#000000]I’m new to SuiteCRM and so far am loving all of the functionality that it has to offer. I’m currently in the process of configuring Suite as my company’s new CRM, and was wondering if I could get some guidance for securing data.

How could I best approach securing custom data fields that hold sensitive info?

I need to create a simple custom module with 3 or 4 custom fields that will hold sensitive client information. I was considering using securitysuite to limit which employees can access this module, but this still doesn’t address that the data itself is stored in plaintext format in the database. Can anyone share any experiences / advice dealing with sensitive info in suite/sugar and how I might be able to avoid storing the data in these fields securely?

Thanks in advance,

You’re on the right track.

You should use securitysuite to restrict which users are able to see the data in the web browser, plus the field data type “Encrypt” which is meant to hold sensitive date such as social security numbers or financial info, in case you ever have a security breach and your database is dumped/completely copied and stolen by cyber criminals looking for sensitive financial info.

More info here, search for keyword “Field Types” and notice the list has “Encrypt” as one of the 21 available field data types.

See lines 83-90 of the studio code. Encrypt field type was removed for Sugar CE.

Probably Sales Agility could re-add the encrypt field type for the next minor update of SuiteCRM if you request it.

Has this been added?

Encrypt field hasn’t been added to SuiteCRM 7.1.4.
It probably should be added to the next possible release, as some data fields really should not be stored in the database unless they’re encrypted for additional safety.

SuiteCRM is based on SugarCRM 6.5 CE so there are no references to an Encrypt field type as they had been removed in 6.3.

Some references to Encrypt field type exist in SugarCRM 6.2.5 CE

  1. include/SugarFields/Fields/Encrypt/SugarFieldEncrypt.php

  2. fieldTypes array element Encrypt needs to be added into

  3. lines 89-90 would need to be commented in

  4. probably a few more.

Those items were removed starting at SugarCRM 6.3.3 CE

To sum it all up, there are a few more lines of code, across several files, that needs to be added in to Suite in order to enable a powerful Encrypt field type in SuiteCRM.

If it was in 6.3 can’t it be grabbed from that version and put into the current version?

I’ve fixed this, tested it, and it works, so I’ve submitted a pull request. Encrypt fields should be back in the next release.

This looks like a nice feature! Thanks!

But this encrypt field… what exactly does it use to encrypt/decrypt? Is it the user name, the user password, what?

I’m thinking about the implications of using such a field for backups, migrations, data access by multiple users, etc.

In short: how could this go terribly wrong? : - )

  1. It uses a single large global key, which is stored in a PHP file, to encrypt the field.
    The CRM will encrypt the field just before writing it out to the database.
    And, just as the CRM reads in the Encrypted field from the database, it decrypts the field.
    So all the data inside the CRM is clear text. And all the “Encrypt” field data on the database is Encrypted.

  2. As long as you keep your website PHP code files together with your database , then your backups and migrations will be fine.
    So, if you restore a backup to an instance without that key, or with a different key, they then Encrypt fields will decrypt incorrectly to garbage text.

I’d add better key management to SuiteCRM, to prevent any unexpected data garbling from occurring after a backup or migration to an instance without the original key.

Thanks for the explanations.

I guess some “visibility” of that key would be convenient; admins must know that exists and take responsibility for
a) protecting it and
b) having appropriate backups.

Another thing that could be desirable is to integrate this a bit into the existing security suite. For example, if the access to the key by certain users could be defined in a security group, so I could say that managers get to see that field, but regular users don’t. This shouldn’t be too difficult to achieve.

Anyway - these are just brainstorming ideas, the current fix is already a useful enhancement.

I wonder why they removed such a useful, and already developed, feature? Could it be those legal issues surrounding encryption exports from the USA? Should we worry about that?

Could it be possible to allow users to define their own key?

  1. Good points. It would be nice to have a section of the admin screen where the admin(s) can set the behavior of the Encrypt feature in some sensible ways. Security suite could prevent users from creating/reading/updating/deleting the information unless it is necessary for their roles.

  2. This Encrypt feature seems to have been created to prevent the theft of sensitive private information by hackers (and evil sys admins) who steal the entire database by doing the shell command mysqldump (or by taking a nightly full backup of the system as part of their job! And then take home the backup to browse through it and steal valuable information). The Encrypt feature encrypts cleartext with one symmetric key.

This Encrypt algorithm is from the mid-1990s.

The drawback to storing the one complete key in a file on the server filesystem, the system is vulnerable to a hacker or evil sys admin who knows that they have to not only steal the database contents with mysqldump, but also steal the file containing the key. If the bad guy is uninformed about this key stored in a file, then they will probably fail to copy it, or fail to know how to make use of it, and fail in their plan to steal the financial or other sensitive information. But, since this is open source, they are probably reading the openly available information, and have just learned how to successfully run away with the sensitive encrypted data :frowning:

So a better 2016 encryption model would be to not store the entire secret key on the filesystem, instead, maybe store only part of the key on the suitecrm server, and another part of the key on some other third party server. There are some open source solutions that can help achieve this, or it can be built.

  1. The exporting of encryption software from the US to other countries requires applying for a license from US Dept of Commerce, which requires disclosing the algorithm used and the country it’s being sold to, and is approved 95% of the time as long as you’re not exporting to troublemaker terrorist countries, north korea, etc. Read more here

Yes. There is much room for development of this Encrypt feature. Many ideas come to mind. Instead of a default key hard coded in file on the filesystem, the admin could have a screen on the Admin page where they could select a new key, such as, they type in a long password type of thing which generates a key for use by the Encrypt algorithm.

Another enhancement is to have one key per Security Group. The Security Groups app could detect which person entered that data field of the record, and which Security Group they are member of, and from delegation rules, decide who can create/update/read/delete that field.

I am brand new to SuiteCRM and am hoping this encrypted field ability is still available. I have downloaded the latest version, yet when I go into Studio and click on “Add Field,” there is no “Encrypted” option in the drop down list of available field types.

I’m wondering if I am missing something or if it’s been removed? In the above thread, it seems to suggest it was added three months ago. But I’m not seeing it.

Thanks for your help!

I provided the code, in July 2016, to re-enable the Encrypt field, to SalesAgility, our heroic maintainers SuiteCRM, on the github page for SuiteCRM. The SA developer team hasn’t yet added it into the SuiteCRM app, although they looked at it in September and labelled it an enhancement. If you want, you could go on github, register a username, and comment that you’d like it included give your reasons, and they’ll possibly bump up the priority, and add it back in sooner. On this page:

1 Like

Thanks! I have commented on this at Github.

Hopefully that will help to get this enhancement into SuiteCRM :slight_smile: