function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
StarfishStarfish 

Securely Create a Protected Custom Setting

I've just had a package rejected from the AppExchange for 'Insecure Storage of Sensative Data.' This is because I had the Post-Install script create a Protected Custom Setting which contained an API Secret and API Key. The trouble, apparently, is that both of these are visible in the Apex Class, though it is a managed package, so those are inaccessible to users by any means I know of.

Thus my question is how are we supposed to create Protected Custom Settings in a secure manner? The trouble is that the user is not supposed to have access to the API Key or API Secret. We cannot have them create the Protected Custom Setting. The API Key and API Secret are the same for everyone who uses the package, so these must be added in an automated fashion, securely. But I don't see how this is possible if the code itself is considered insecure.
AshwaniAshwani
Solution 1:
You have to create a "Settings" tab where user will enter API secret and API key. You have to provide some documentation for it.

Solution 2:
Encrypt API secret and key and decrypt in real time when post install script run.

You can not directly write these critical details in a variable.
StarfishStarfish
But to be clear, for Solution 2 (solution 1 is not viable as we do not want the user to know the secret or key), we would be storing the Encrypted API secret and key in variables/text within the code? If we assume that the code itself is vulnerable, I'm not sure how that is any more secure, as we are handing them both the encrypted information and the decryption algorithm. Could you please explain? Thank you.
AshwaniAshwani
In brief, Password/Credentials must not be human readable. If it is, it means it has been read by your colleague, salesforce.com and anyone who can access your apex files.
Its not about you have managed package and it won't be visible at customer end. If it is encrypted it can not be decoded without knowing encrytion algos and a programming language. At least these precaution must be taken.
James LoghryJames Loghry
Another option is to default the protected custom settings using an InstallHandler class (see here: https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_install_handler.htm).  Note, this doesn't provide a mechanism for the installer to go and update the custom settings though like Jellyfish's solution would, but it's more simple.