Developers - rethink secrets storage / Summit Events Settings custom setting

[jhilyard]

See warning at: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_customsettings.htm Storing secrets like the encryption key, uPay-related secrets (validation key, etc.) is not considered good practice unless the custom setting is "protected" and within a managed package. If that's the case, it can't be changed in the Salesforce settings UI, so there would need to be a custom-coded UI for manipulating the settings. The reference above recommends using named credentials and encrypted custom fields for secrets storage.

[jhilyard]

The encryption key could be in a protected managed custom setting (simplest would be hierarchy/org level; if we think we need to support separate sites we could do profile-level (per site guest user) since it doesn't need to be known to users or even admins. We can't assume orgs have custom list settings enabled, so hierarchy is a better choice if we use custom settings. We could have a settings tab in the app with a button to initialize/re-initialize it to a random value. Named credentials might make sense for a payment provider scenario like TouchNet T-Link where there is a call out, but not for uPay since there isn't a call out. Security concerns raised in the for public custom settings or "protected" custom settings outside a managed package (which behave like public custom settings) include that custom settings are listed in the Enterprise WSDL (which might be downloaded and given to a SOAP developer who doesn't need to know the encryption key) and are accessible via APIs, where a misconfigured security setting (i.e. allowing REST API access to site guest user) could expose secrets. Custom metadata types (including actual data values) can be deployed, and production values are included in developer sandbox refreshes/creation. I'm not convinced that would be a good thing for all settings.