FAQ-001426 - Password Management Security / Managed Package Security

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What are the security requirements for password handling and storage in managed packages?
Answer
Password handling and storage in managed packages must follow these security requirements: 1. **Encryption**: Passwords should never be stored in plain text. Use Salesforce's Apex Crypto calls for encryption, and store encryption keys securely in protected custom settings or hidden custom metadata API fields. 2. **Access Control**: If passwords are stored in custom objects, ensure the fields are encrypted and permissions are configured to restrict access. 3. **Authentication Data**: Avoid using encrypted fields for authentication data. Instead, store such data in named credentials or protected custom settings. 4. **Transient Keywords**: Use transient keywords in code to prevent storage in viewstate when updating settings. 5. **Avoid Obfuscated Formats**: Do not write passwords or secrets to property files, XML files, or other obfuscated formats. 6. **Client Applications**: Store secrets in OS vendor-supplied keystores, such as the keychain for Mac, DP-API for Windows, or gnome-keyring for Linux. 7. **Server Applications**: Use vendor-supplied encryption functionality or recognized third-party cryptographic toolkits to protect credentials against vulnerabilities like SQL injection.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexBadCryptoApexSuggestUsingNamedCredAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInVarDeclsAvoidHardcodedCredentialsInVarAssignAvoidHardcodedCredentialsInHttpHeaderAvoidHardcodedCredentialsInSetPasswordAvoidUnsafePasswordManagementUseProtectSensitiveData
Question
What are the security requirements for password handling and storage in managed packages?
Recommended Answer Update
Password handling and storage in managed packages must follow these security requirements: 1. **Encryption**: Passwords should never be stored in plain text. Use Salesforce's Apex Crypto calls for encryption, and store encryption keys securely in protected custom settings or hidden custom metadata API fields. 2. **Access Control**: If passwords are stored in custom objects, ensure the fields are encrypted and permissions are configured to restrict access. 3. **Authentication Data**: Avoid using encrypted fields for authentication data. Instead, store such data in named credentials or protected custom settings. 4. **Transient Keywords**: Use transient keywords in code to prevent storage in viewstate when updating settings. 5. **Avoid Hardcoded Secrets**: Don't hardcode passwords or secrets in field declarations, variable assignments, HTTP headers, or property files. Instead, use secure storage mechanisms like named credentials. 6. **Client Applications**: Store secrets in OS vendor-supplied keystores, such as the keychain for Mac, DP-API for Windows, or gnome-keyring for Linux. 7. **Server Applications**: Use vendor-supplied encryption functionality or recognized third-party cryptographic toolkits to protect credentials against vulnerabilities like SQL injection.
Reasoning
The FAQ content is generally accurate but contains imprecise language that should be refined for clarity and technical accuracy. The main issues addressed: 1. **Improved precision in point 5**: Changed 'Avoid Obfuscated Formats' to 'Avoid Hardcoded Secrets' to better align with the specific security concern. The original wording was confusing because obfuscation isn't inherently bad - the real issue is hardcoding credentials in code, which multiple security rules address. 2. **Enhanced clarity**: The updated language more clearly connects to the actual security violations that scanner rules detect. Regarding the selected security rules: - **ApexBadCrypto**: Relates to point 1 about using proper Salesforce Apex Crypto calls for encryption - **ApexSuggestUsingNamedCred**: Directly supports point 3 about storing authentication data in named credentials - **AvoidHardcodedCredentialsInFieldDecls**: Addresses point 5's prohibition against hardcoding passwords in field declarations - **AvoidHardcodedCredentialsInVarDecls**: Relates to point 5's guidance against hardcoding in variable declarations - **AvoidHardcodedCredentialsInVarAssign**: Covers point 5's restriction on hardcoding in variable assignments - **AvoidHardcodedCredentialsInHttpHeader**: Supports point 5's guidance about HTTP headers mentioned in the FAQ - **AvoidHardcodedCredentialsInSetPassword**: Aligns with the FAQ's overall password security theme - **AvoidUnsafePasswordManagementUse**: Directly relates to the entire FAQ's focus on secure password management practices - **ProtectSensitiveData**: Encompasses the general theme of protecting sensitive credential information discussed throughout the FAQ
Reasoning References