+ Start a Discussion

Securely Storing Sensitive Information within Force.com

Some applications may require storage of sensitive data within Force.com. This includes usernames, passwords, authentication keys, credit card numbers, social security numbers, etc. Hiding these fields from specific page layouts does not provide adequate protection since these fields remain accessible via the API, unless otherwise protected using CRUD & FLS settings.

There are two ways to protect sensitive data within Force.com:


Custom Settings (Preferred): 
Custom settings are similar to custom objects and enable application developers to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. However, setting the visibility of the Custom Setting Definition to “Protected” and including it in a managed package ensures that it’s only accessible programmatically via Apex code that exists within your package. 

In order to allow authorized users to create and update sensitive information, create a Visualforce page that only accepts input and does not render the value back on the page. The “transient” keyword should be used to declare instance variables within Visualforce controllers to ensure they are not transmitted as part of the view state. Please refer to the following link for details: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_keywords_transient.htm
Finally, configure the security settings for this page to ensure it’s only accessible by limited profiles on an as needed basis.

For more information, search for "Custom Settings" under Help & Training within any Salesforce org.
Encrypted Custom Fields:
Encrypted custom fields are text fields that can contain letters, numbers, or symbols but are encrypted with 128-bit keys and use the AES algorithm. The value of an encrypted field is only visible to users that have the “View Encrypted Data” permission.

The disadvantage of this method to protect data is that you must request salesforce.com to enable encrypted fields on a per-org basis. Additionally, such fields are always accessible by administrative users.