12

Regarding the Salesforce security review process, can anyone confirm (or deny) that storing a connection URL, username and password for a webservice utilized by an appexchange app can be done in plain text so long as it is within a protected custom setting record, and an appropriate interface (or initialisation script) is provided for accessing these fields?

ie. I have a protected custom setting record, and a "safe" way of injecting the values. Can I therefore store the password simply as a text field, or do I also need to go through the process of encrypting/decrypting the text in order to satisfy a security review?

This excerpt from the checklist suggests so to me - as it refers to encryption as "another option", but I would love to get some real-life feedback from other developers' experience.

Ensure that sensitive information is not available to all users in a customer org. This can be achieved by using Custom Settings in "Protected" mode, and creating a Visualforce page for authorized users to update information. The previously stored data should not be displayed back to the user on this page. Another option is to implement Apex Crypto and store the encryption key in a protected custom setting. For more information see the Secure Cloud Development entry for Storing Secrets.

Improve this question

2 Answers 2

Reset to default
11

You don't need to encrypt the password if it is never visible to the user. Protected settings are impossible to access, even by administrators, outside of the code provided by the developer of the managed package. That is what is meant by "protected."

The second option mentioned specifies storing a key in protected settings and letting the user see the encrypted value. For example, this technique might be used if the field is in a record on a standard or custom object.

By storing the key in a custom setting, the data can be stored or even extracted without revealing the secrets the data contains. For example, this may be useful in an integration system where each record in an object represents a different protected resource.

Improve this answer
1
  • Each answer here has been really useful, so thank you both @Eric and sfdcfox, I will mark this as the accepted answer though as I think in months to come it sounds slightly more concrete.
    – Simon Lawrence
    Commented Nov 4, 2014 at 10:14
6
  1. If they know it is a password then they may require you to encrypt it
  2. If it is a salesforce password you cannot store it in any way shape or form or you will fail review
    • I just went through this and it is an immediate fail to store a salesforce password (at least that is what I was told - call again and maybe get a different answer)

Otherwise a protected custom setting should be good enough. The problem is that you as the developer can see the password to the external system as can anyone who has access to your org when granted login access by the subscriber. For that reason I would encrypt it as well to provide the customer an extra layer of "comfort" when they ask how the password is stored.

Improve this answer
2
  • Interesting, thank you. It isn't a Salesforce password, it is for a totally separate third party webservice. I guess I will have to have a look at the overhead for implementing an encryption/decryption process.. I don't think it's too bad tbh.
    – Simon Lawrence
    Commented Nov 3, 2014 at 12:58
  • 1
    How would you store the key that was used to encrypt it? If you have access to the key, you have access to the password if its encrypted or not.
    – TemporaryFix
    Commented Oct 7, 2021 at 15:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .