In ASP.NET Core, any code in the project can be checked into some code repository using the 'user secrets' of Microsoft. This API was recently introduced to keep sensitive data out of the project folder. Besides, sensitive data will not be included since these secrets are stored in a user's profile subfolder and kept outside the project. User secrets are not a trusted store since their content will be unencrypted. Apart from that these are only intended for development work.
What are User Secrets?
User Secrets are all about the developer's secrets and are never meant to be end user's secrets. Below are a few scenarios where developers have secrets.
• When there are user-specific passwords present which is used for accessing databases. Often, many enterprises never provide the developers' accounts to access databases.
• Different Social Media APP keys that are used when development is secret. Facebook/Twitter/Google API keys are one's secret and there is no need to place them in source code.
• Any sort of Token value that is used for accessing some services.
Also, developers need to be alert when they are working with source code repos. One should be careful to place some dummy text there. Furthermore, to enter their respective secrets, there should be a common understanding between the developers.
How to manage secrets in asp.net core web applications
In many instances, there is a variety of sensitive information that is required to be stored in application configurations in in-app settings. However, during the development process of API keys, database connection strings, passwords, and S3 configurations, developers often check in wrong sensitive information in the working repositories. Further, all this information should never be exposed in public, should not be part of app settings, and must be managed outside the project source control. .NET Core has already introduced a tool called the User Secrets manager tool. This is an effective tool that can be used while storing application variables outside the application folder. User Secrets is the preferred and functional way to store sensitive values for local development. The User Secrets manager tool helps to manage to store configuration values that are outside the working directory of your project. Although it is important to be aware that User Secrets doesn't encrypt the secrets, this works well for local development. User Secrets are moved to a location you are less likely to accidentally expose.
Storing secrets for local development
The major challenge one will need to solve while using user secrets is the process of making sure that the secrets are not visible to the outside world or public as a part of the code. All the frameworks have their strategy in dealing with application secrets safely and securely and secret management is a well-known topic. Users want all secret configurations to be separate from their code. This applies both to the production environment as well as the local development environment. For instance, developers usually ass a secret database connection string along with a password in the application configuration file(e.g. appsettings.json or web.config). These secrets are available to anybody who has access to code and are usually a part of source control.
The imminent advent of the GDPR helps in reminding the users once again the necessity of keeping any sort of sensitive data that is managed by applications secured as well as safe. Besides, we have a comparatively easy API that can be used to encrypt the content of the selected sections of the web.config file in classic ASP.NET applications. However, many feel that with the rising need to encrypt configuration data API has already lost its attraction and appeal over the last few years. Another factor that has led to an increase in this trend to lose interest in encryption is the success of source code platforms such as Github.
Consequentially, a large amount of potentially critical data such as connection strings and API keys have been published as clear text in public repositories. The entire infrastructure for securing and managing configuration data has been rewritten from scratch in ASP.NET Core. A variety of data providers have replaced the web.config files and this has led to the disappearance of web.config files web.config files. ASP.NET Core consists of user secrets. But, none of the web.config files has encryption capabilities.
Defining Sensitive Data of Application
In simple words, a user secret is any form of application data that one wants to keep secret. Also, the canonical examples of software user secrets are client IDs, API keys, database connection strings, SaaS applications, and secrets to access social networks. User secrets often consist of several pieces of information that are application-specific and sensitive, like tokens to access online services as well as the credentials to access payment gateways.
Whether it be TFS or Github, the safest thing to do is to keep secrets outside the scope of the code repository during the enthusiastic days of shared code repositories. By design, user secrets in ASP.NET Core are stored outside the project so that the project can be quickly or easily published and checked-in on the public without worries and anxiety. One might want to protect certain pieces of application data, called user secrets while working with ASP.NET web applications. This application data cannot be shared with other people. Your user secrets might often consist of a database connection string. This database connection string also contains the password as well as the user ID for the database. One might also wish to refrain from sharing information such as connection information details regarding cloud services such as AWS or Azure, API keys, and access keys.
However, secret information also will be shared if you share your project with other users or developers. How can one prevent the sharing of secret information? User Secrets, which is a feature in ASP.NET Core allows you to manage user secrets using a command-line tool called the Secrets Manager. Apart from that this allows you to store user secrets outside your project tree in a JSON file.
However, Secret information should never be pushed to any sort of public source code repository. Most credentials are often stored safely in .config files. One will need to configure the credentials FTP, mail servers, as well as storage. Further, you should also configure access to a database. In many instances, credentials often find application in the development, with a lot more rights than the production credentials. Secret information should not be pushed to any source code repository.
What is the feasible solution to tell our app where to get this secret information? you can easily configure your settings in the application settings of your web app on Azure. However, regardless of whether it is an appsettings.json or a web.config, this usually overrides the settings of your config file. But one cannot perform the same on the local development machine since there is no configuration available for doing so. Where and how do we save secret credentials? The .NET Core SDK (Microsoft.Extensions.SecretManager.Tools) now provides the SecretManager tool with which you can access with the CLI.
This tool assists you in storing your secrets locally and safely on your machine. This is not highly secure and is not a high secure password manager. But is a high secure password manager on your development machine. Moreover, it provides you with the possibility of not storing your secrets in a config file inside your project.
Over the past few years, developers perceived the encryption of sensitive data as a low priority task. But it is very important to encrypt sensitive data. Microsoft recently introduced 'user secrets' in ASP.NET Core. This is an API that works towards to keep sensitive data out of the project folder. In other words, this means that there will be no sensitive data will be included with the code since those secrets are usually stored in a user's profile subfolder and kept outside the project if any code in the project is checked into some code repository. This means that User secrets are not a trusted store because their content is unencrypted and is only intended for development work. Azure key vault or Azure application settings are the options often preferred to save secrets within Azure. Finally, by looking back at non-Core ASP.NET, we found out that the encryption of sections available in the web.config file is a useful feature that has been available since ASP.NET 2.0. No more excuses will permit you to skip the chore of protecting or encrypting in some serious way any sort of sensitive data like connection strings.