Connection strings. They are a part of every project, easily overlooked and yet very important to do the right way. A connection string represents a potential vulnerability if it is not secured. I hope it’s widely understood that storing information in plain text could compromise your entire application.
Security vulnerabilities involving connection strings can arise based on the type of authentication used, how connection strings are persisted in memory, and the techniques used to construct them at run time.
When I think of connection strings, I think of error messages and messing around with permissions, because I just want to get things going on a new project. However, the way we store connection strings and other secrets is super important.
Where do you store your connection strings?
There are a few different ways to configure your connection strings. You can hard code it (not recommended), put it into appsettings.json, or secrets.json, or you could use Key Vault (recommended).
I did a Microsoft Forms survey to the SSW developers, and it confirmed the preference was Key Vault.
Unlocking the Key Vault in Microsoft Azure
So how do we avoid leaking our secrets? If you want to avoid accidently leaking passwords or secrets, you can use a tool like Microsoft Key Vault to encrypt keys and small secrets like passwords (less than 25k).
Key Vault requires understanding a few key concepts. Azure Key Vault is great for keeping your secrets secret because you can control access to the vault via Access Policies. The access policies allow you to add Users and Applications with customized permissions. Make sure you enable the System assigned identity for your App Service, this is required for adding it to Key Vault via Access Policies.
Visual Studio – You can integrate Key Vault directly into your ASP.NET Core application configuration. This allows you to access Key Vault secrets via
Tip: You can detect if your application is running on your local machine or on an Azure AppService by looking for the WEBSITE_SITE_NAME environment variable. If null or empty, then you are NOT running on an Azure AppService.
If you want to see how to set up Key Vault correctly, see our Rule “Do You Know How To Use Connection Strings”
There are other options for securing secrets, like using Managed Identities.
If you use a Managed Identity, you can remove the identity type parameters (access keys and passwords) and your connection string is then information that no longer needs to be secured. So you can just store the connection string in your standard app settings along with all the URLs and other configurations.
Therefore, Managed Identities basically eliminate the need for developers to manage credentials at all. Managed Identities provide an identity for applications to use when connecting to resources that support Azure Active Directory authentication. Applications may use the Managed Identity to obtain Azure AD tokens. For example, an application may use a Managed Identity to access resources like Azure Storage, or Key Vault, which is still the best place to store credentials you need to access resources not accessible with a managed identity.
Here are some of the benefits of using Managed Identities:
- You don’t need to manage credentials. Credentials are not even accessible to you.
- You can use Managed Identities to authenticate to any resource that supports Azure Active Directory authentication including your own applications.
- Managed Identities can be used without any additional cost.
For a great example of how to use Managed Identities check out Bryden Oliver’s GitHub: https://github.com/brydeno/bicepsofsteel
Bryden is also doing a lightning talk for the Sydney .NET User Group on Wednesday 16th June if you want to tune in: www.ssw.com.au/ssw/live
Lock your Vault!
So now you know at least two different awesome ways to secure your secrets! We have no excuse for accidently exposing them to the world and it’s simple to use.
What is your favourite way to store your secrets? I’d love to hear about any good or bad experiences you’ve had!