Consilat (A Salesforce Consulting Company)
Salesforce Encryption: There are many instances where you want to encrypt your data and want to store them on custom fields, but, want to display the information only to a set/group of users. For this we can use Encrypted Text fields provided by Salesforce which encrypts the data using Classic Encryption.
Pre-requisites while Implementation:
- Users with permission “View Encrypted Data” can see data in encrypted custom text fields.
- The organization should have “Require secure connections (HTTPS)” enabled.
- In Visualforce pages, only the <apex:outputField> tag supports the use of encrypted fields.
- Only users with the “View Encrypted Data” permission can clone the encrypted field when cloning a record.
- One can always use the encrypted fields on an email template, but the value for those fields will always be hidden/masked even if the user has “View Encrypted Data” permission granted.
Limitations while Implementation:
- The encrypted fields cannot be Unique and neither have an External Id nor Default values.
- Only 175 characters are allowed because of the encryption algorithm.
- These type of fields cannot be used as a filter criteria in list views, reports, roll-up summary fields.
- Cannot be used as rule filters or in report criteria.
- For obvious reasons, the field in not available for searching.
- These fields are not available for workflow rule criteria or formulas, lead conversion, formula fields, outbound messages, default values, and Web-to-Lead and Web-to-Case forms.
Considerations while Implementation:
- Make use of validation rules, field-level security settings, or page layout settings to prevent users from editing encrypted fields, as they editable regardless of only the user has the “View Encrypted Data” permission.
- The data in an encrypted field is not always masked in the debug log.
- Existing custom fields cannot be converted into encrypted fields nor can encrypted fields be converted into another data type directly. You can create a new encrypted field and load the data in that newly created field only.
- Performance can be impacted, as encryption involves more processing.
Shield Platform Encryption
Platform encryption can be used to encrypt a variety of standard fields along with some custom fields and attachments stored in Salesforce.
- It makes use of 256-bit Advanced Encryption Standard (AES) as compared to 128-bit Advanced Encryption Standard (AES) used in Classic Encryption.
- Encryption support is provided to existing custom fields.
- Can be searched via (UI, Partial Search, Lookups, and certain SOSL Queries).
- Can be used in Workflow Rules and Workflow Field Updates.
- It is also available in Approval Process Entry Criteria and Approval Step Criteria.
Shield Platform Encryption Process Flow
The Shield Platform Encryption Process works on the concept of providing secret keys as inputs. Salesforce securely generates the master and tenant secrets is derived on demand and is passed to the search engine’s cache on a secure channel when a Salesforce user searches/saves encrypted data.
- Before storing/committing the data to the database, the runtime engine determines from metadata whether to encrypt the field.
- Only if the first step is successful, then the encryption service checks for the matching data encryption key in cached memory.
- The encryption service determines whether the key exists:
- If so, the encryption service retrieves the key.
- If not, the service sends a request to a key derivation server and returns it to the encryption service running on the Salesforce Platform.
- After retrieving the key, the encryption service generates a random initialization vector (IV) and encrypts the data using 256-bit AES encryption.
- The IV and corresponding ID of the tenant secret used to derive the data encryption key are saved in the database.
Apex Crypto Class
Crypto class provides various cryptographic methods that are used to provide content security or encrypting and decrypting information. They are also used for integrating with external services such as Google or Amazon WebServices (AWS).
The cryptographic capabilities of the Crypto class are normally used in the following scenarios:
Confidentiality – the protection of data whether it is at rest or in transit from unauthorized parties.
Integrity – the data is complete and correct.
Authenticity – proof of the authenticity of the sender or receiver of the message.
Encryption and Decryption is the most common mechanism for data protection, but, it does not authenticate the sender and nor does it guarantee message integrity.
The following are the various supported standards for each of the Crypto class methods.
- encrypt(algorithmName, privateKey, initializationVector, clearText)
- encryptWithManagedIV(algorithmName, privateKey, clearText)
- decrypt(algorithmName, privateKey, initializationVector, cipherText)
- decryptWithManagedIV(algorithmName, privateKey, IVAndCipherText)
A private key can either be generated externally. The length of the private key must match to the specified algorithm.
The private key should be placed in a protected custom setting and should not be hardcoded in the Apex code.
The above article describes the cryptographic capabilities of the Force.com platform, including functions to the most common encrypt and decrypt data protection technique using the AES algorithm while there are also some advance mechanisms to provide more security, integrity and authenticity like Generate Digests, Message Authentication Codes and Digital Signatures.