Most systems will have variables that need to be stored securely; OpenId shared secret keys, connection strings, and API tokens to name a few.
These secrets must not be stored in source control. It is insecure and means they are sitting out in the open, wherever code has been downloaded, for anyone to see.
There are many options for managing secrets in a secure way:
Store production passwords in source control
Pros:
Cons:
Passwords are readable by anyone who has either source code or access to source control
Difficult to manage production and non-production config settings
Developers can read and access the production password

❌ Figure: Bad practice - Overall rating: 1/10
Store production passwords in source control protected with the ASP.NET IIS Registration Tool
Pros:
Cons:
Need to manually give the app pool identity ability to read the default RSA key container
Difficult to manage production and non-production config settings
Developers can easily decrypt and access the production password
Manual transmission of the password from the key store to the encrypted config file
❌ Figure: Bad practice - Overall rating: 2/10
Use Windows Identity instead of username / password
Pros:
Cons:
Difficult to manage production and non-production config settings
Not generally applicable to all secured resources
Can hit firewall snags with Kerberos and AD ports
Vulnerable to DOS attacks related to password lockout policies
Has key-person reliance on network admin
❌ Figure: Bad practice - Overall rating: 4/10
Use External Configuration Files
Pros:
Cons:
Makes setting up projects the first time very hard
Easy to accidentally check the external config file into source control
Still need DPAPI to protect the external config file
No clear way to manage the DevOps process for external config files
❌ Figure: Bad practice - Overall rating: 1/10
Use Octopus/ VSTS RM secret management, with passwords sourced from KeePass
Pros:
Cons:
✅ Figure: Good practice - Overall rating: 8/10
Use Enterprise Secret Management Tool – Keeper, 1Password, LastPass, Hashicorp Vault, etc
Pros:
Enterprise grade – supports cryptographically strong passwords, auditing of secret access and dynamic secrets
Supports hierarchy of secrets
API interface for interfacing with other tools
Password transmission can be done without a human in the chain
Cons:
✅ Figure: Good practice - Overall rating: 8/10
Use .NET User Secrets
Pros:
Cons:
✅ Figure: Good practice - Overall rating 8/10
Use Azure Key Vault
See the SSW Rewards mobile app repository for how SSW is using this in a production application: https://github.com/SSWConsulting/SSW.Rewards
Pros:
Enterprise grade
Uses industry standard best encryption
Dynamically cycles secrets
Access granted based on Azure AD permissions - no need to 'securely' share passwords with colleagues
Can be used to inject secrets in your CI/CD pipelines for non-cloud solutions
Can be used by on-premise applications (more configuration - see Use Application ID and X.509 certificate for non-Azure-hosted apps)
Cons:
✅ Figure: Good practice - Overall rating 9/10
Avoid using secrets with Azure Managed Identities
The easiest way to manage secrets is not to have them in the first place. Azure Managed Identities allows you to assign an Azure AD identity to your application and then allow it to use its identity to log in to other services. This avoids the need for any secrets to be stored.
Pros:
Best solution for cloud (Azure) solutions
Enterprise grade
Access granted based on Azure AD permissions - no need to 'securely' share passwords with colleagues
Roles can be granted to your application your CI/CD pipelines at the time your services are deployed
Cons:

✅ Figure: Good practice - Overall rating 10/10
The following resources show some concrete examples on how to apply the principles described: