ASP. NET Core Security Data Protection

Introduction to data protection for Introduction to data protection

Web applications often need to store security-sensitive data. Windows provides DPAPI for desktop applications, but not for Web applications. Asp. The net core data protection stack provides an easy way to use cryptographic APIs that developers can take to protect data, including key management and exchange.

Asp. NET Core Data protection stack design users to replace the <machineKey> elements in the ASP. 1.x-4.x. The stack design addresses many of the drawbacks of the password stack, while providing solutions for most of the cases that modern applications may encounter.

Problem Statement Problem Statement

The overall problem statement can be simplified as a sentence: I need to provide a persistent information store for later retrieval, but I don't trust the storage mechanism. In network terms, "I need to get and return a trusted state through an untrusted client." ”

A typical example is a user authentication cookie or bearer token. The server generates an "I am Groot and has XYZ permissions" token and sends it to the client. On a Future day, the client will return the token to the server, but the server needs to determine that the token was not forged by the client. So the first requirement: authenticity (aka integrity, tamper-proof).

Based on persistent state, which is trusted by the server, we expect that this State may contain information for a particular environment. This information can be file paths, permissions, handles, indirect references, or server-specific data. Typically, this type of information should not be disclosed to untrusted clients, thus creating a second requirement: confidentiality.

Finally, because the modern program is also modular, we see that individual components will want to take advantage of the system without thinking about other components of the system. For example, if a bearer token component is using this stack, it should not be disturbed by an anti-CSRF (cross-site request forgery) mechanism that may also be using the same stack. Thus the last requirement was created: isolation.

We can provide further constraints to narrow the scope of demand. Assume that all servers running within an encrypted system are equally trusted and that the data is not generated and consumed by external services under our control. In addition, we need to run everything as quickly as possible, because every request made to the Web server enters the encryption system one or more times. This makes the symmetric cipher system the ideal choice for our program. We can ignore the asymmetric encryption system until it is needed.

Design philosophy Principle

Let's start with the existing stack to discover the problem. Then, by investigating the existing solutions, we can conclude that the existing solutions are not up to our requirements. We then design a solution based on a few guiding principles:

• The system should be simple to configure. Ideally, the system should be 0 configured, and developers can start working immediately. If a developer needs to configure for a facet (for example, a key repository), consider making these settings as concise as possible.
• Providing a simple user-oriented api,apis should be easy to use correctly and error-prone.
• Developers should master Key management principles, and the system should handle algorithm selection and key generation time on behalf of developers. Ideally, developers should not even have access to the original key.
• If possible, the key should be protected in a dormant state. The system should specify an appropriate default protection mechanism and use it automatically.

As a result, we have developed an easy-to-use data protection stack.

ASP. NET Core Data protection APIs were not initially used to encrypt the load's indeterminate persistence. Other technologies such as Windows CNG DPAPI and Azure rights Management are better suited for uncertain storage scenarios and respond to these technologies with strong key management capabilities. However, there is nothing that prevents developers from using ASP. NET Core Data protection APIs for long-term protection of encrypted data.

Audience audience

The data protection system is divided into 5 main modules, the different aspects of the APIs face three main audiences;

1. Consumer APIs Overview for application and framework developers.
   
   "I don't want to know how the stack works and how to configure it. I just want to improve the probability of successful use of APIs in the simplest possible way. ”
   
   
2. Configuration APIs face application developers and system administrators.
   
   "I need to inform the data protection system that our environment requires non-default paths and configurations. ”
   
   
3. Extensibility APIs face developers who are responsible for executing custom policies. The use of these APIs is limited to special cases and experienced, security-minded developers.
   
   "We need to replace a complete component within the system because we have unique behavioral needs. I would like to learn the less common parts of the API for building a plug-in that meets your needs. ”

Package Layout

The data protection stack consists of five modules.

• The Microsoft.AspNetCore.DataProtection.Abstractions contains the basic idataprotectionprovider and Idataprotector interfaces. It also contains extension methods that can assist with these types (for example: Idataprotector.protect overloads). For more information, see the User Interface Usage section. If someone is responsible for instantiating the data protection system, you can refer to, Microsoft.AspNetCore.DataProtection.Abstractions.
• The Microsoft.AspNetCore.DataProtection includes core implementations of data protection systems, including core encryption, key management, configuration, and scalability. If you are responsible for instantiating a data protection system (for example, adding it to a iservicecollection) or modifying and extending its behavior, you can refer to Microsoft.AspNetCore.DataProtection.
• Microsoft.AspNetCore.DataProtection.Extensions contains some additional APIs that developers might use. But it does not belong to the core module. For example, this module contains a simple API "that will point to a specific key store directory instantiation without the dependency injection into setup." "At the same time, it includes an extension method to protect the payload's restricted life cycle (more information).
• Microsoft.AspNetCore.DataProtection.SystemWeb can be installed into an existing ASP. NET 4.x application and redirect its <machineKey> run. The new data protection stack is used. For more information, see compatibility.
• Microsoft.AspNetCore.Cryptography.KeyDerivation provides an implementation of the PBKDF2 password hashing program and can be used for systems that require secure handling of user passwords. For more information, see Password Hashing .

So many years of the first article, we have a lot of attention. Follow slowly to ~ ~

ASP. NET Core Security Data Protection