Protection des données de base ASP.NET

Interface API

ASP.NET Core Data Protectio fournit principalement deux interfaces pour les développeurs ordinaires, IDataProtectionProvider et IDataProtector.
Voyons d'abord la relation entre ces deux interfaces :

namespace Microsoft.AspNetCore.DataProtection
{
 //
 // 摘要:
 //  An interface that can provide data protection services.
 public interface IDataProtector : IDataProtectionProvider
 {
 
  byte[] Protect(byte[] plaintext);
 
  byte[] Unprotect(byte[] protectedData);
 }
}

Comme vous pouvez le constater, IDataProtector hérite de IDataProtectionProvider et fournit deux méthodes, Protect et Unprotect, nommées de Il semble que l'un soit le cryptage et l'autre le décryptage. Leurs signatures sont transmises dans un tableau d'octets, ce qui signifie qu'ils peuvent chiffrer et déchiffrer tous les objets. Ce qui est renvoyé est également un tableau d'octets, ce qui signifie qu'en utilisation réelle, nous devons l'ajouter nous-mêmes ou utiliser certaines méthodes d'extension du système pour spécifier nos besoins.

Regardons à nouveau l'interface IDataProtectionProvider :

namespace Microsoft.AspNetCore.DataProtection
{
 public interface IDataProtectionProvider
 {
 
  IDataProtector CreateProtector(string purpose);
 }
}

IDataProtectionProvider fournit une méthode en passant une chaîne d'objectif (voir les détails ci-dessous) Pour générer un objet d'interface IDataProtector.
À en juger par le nom de cette interface, elle se termine par Provider, ce qui signifie que dans cette partie, nous pouvons implémenter notre propre ensemble d'éléments de cryptage et de décryptage.

Quand on lit le code source des projets Microsoft, on voit souvent certains objets se terminer par xxxxProvider Alors quelles sont ses responsabilités et quel rôle joue-t-il ?
En fait, il s'agit d'un modèle de conception spécialement conçu par Microsoft pour ASP.NET, appelé modèle de conception Provider Model. On peut également dire qu'il a été inventé par Microsoft. Il n'appartient à aucun des 23 modèles de conception. D'un point de vue fonctionnel, si tel est le cas, il devrait s'agir d'une combinaison d'usine et de stratégie. Microsoft a introduit ce modèle de conception depuis ASP.NET 2.0, initialement principalement pour implémenter plusieurs implémentations de configuration d'application. Par exemple, web.config, qui est le plus familier aux développeurs, est destiné à la configuration des chaînes de connexion aux bases de données, binaires, XML, etc. Ce mode est désormais de plus en plus utilisé ailleurs.

Parlons de la chaîne d'objectif dans la signature de la méthode CreateProtector. Dans le billet de blog précédent, pour faciliter la compréhension des lecteurs, j'ai dit que l'objectif entrant peut être compris comme une clé publique. en fait, cette déclaration n'est pas rigoureuse et peut être comprise comme un logo indiquant le but du protecteur actuel.

Lorsque vous utilisez IDataProtector, vous constaterez qu'il dispose également de certaines méthodes d'extension situées sous l'espace de noms Microsoft.AspNetCore.DataProtection :

public static class DataProtectionCommonExtensions
{
 public static IDataProtector CreateProtector(this IDataProtectionProvider provider, IEnumerable<string> purposes);
 
 public static IDataProtector CreateProtector(this IDataProtectionProvider provider, string purpose, params string[] subPurposes);
 
 public static IDataProtector GetDataProtector(this IServiceProvider services, IEnumerable<string> purposes);
 
 public static IDataProtector GetDataProtector(this IServiceProvider services, string purpose, params string[] subPurposes);
 
 public static string Protect(this IDataProtector protector, string plaintext);
 
 public static string Unprotect(this IDataProtector protector, string protectedData);
}

Comme vous pouvez le constater, CreateProtector fournit également des méthodes qui peuvent transmettre plusieurs objectifs (IEnumerable, params string[]). Pourquoi y a-t-il un tel besoin ?

En fait, DataProtector a une structure hiérarchique. Regardez à nouveau l'interface IDataProtector. Il implémente également l'interface IDataProtectionProvider, ce qui signifie qu'IDataProtector lui-même peut également créer IDataProtector.

Par exemple : nous travaillons sur un système de communication par message. Pendant le processus de communication par message, la session de l'utilisateur doit être cryptée. Nous utilisons CreateProtector("Security.BearerToken") pour crypter. Cependant, lors du cryptage, il n'y a aucune garantie que le message soit envoyé par un client non fiable, j'ai donc pensé à CreateProtector("username") pour crypter. À ce stade, s'il y a un utilisateur nommé "Security.BearerToken", alors il. est en conflit avec un autre Protector qui utilise Security.BearerToken comme identifiant, nous pouvons donc utiliser
CreateProtector([ « Security.BearerToken », « User : username » ]). C'est équivalent à
supplier.CreateProtector("Security.BearerToken).CreateProtector("User: username") Cela signifie d'abord créer un Protector appelé "Security.BearerToken", puis créer un Protector nommé "User: username". Protector.

Hachage du mot de passe utilisateur

fournit une méthode KeyDerivation.Pbkdf2 sous l'espace de noms Microsoft.AspNetCore.Cryptography.KeyDerivation pour le hachage du mot de passe utilisateur

.

Cryptage avec restrictions de cycle de vie

Parfois, nous avons besoin de chaînes cryptées avec expiration ou délai d'expiration, comme par exemple un utilisateur recherchant Lors du retour du mot de passe, nous envoyons un e-mail avec une commande de réinitialisation à la boîte aux lettres de l'utilisateur. Cette commande de réinitialisation doit avoir un délai d'expiration. Après ce délai d'expiration, elle deviendra invalide. Dans le passé, nous devions peut-être envoyer une requête à la base de données pour marquer l'heure d'envoi, puis. déchiffrez et comparez le décalage horaire avec la base de données pour vérifier

Maintenant, nous n'avons plus besoin de faire cela. ASP.NET Core fournit une interface appelée ITimeLimitedDataProtector par défaut. à la définition de cette interface :

CreateProtector(string purpose) : ITimeLimitedDataProtector This API is similar to the existing IDataProtectionProvider.CreateProtector in that it can be used to create purpose chains from a root time-limited protector.
Protect(byte[] plaintext, DateTimeOffset expiration) : byte[]
Protect(byte[] plaintext, TimeSpan lifetime) : byte[]
Protect(byte[] plaintext) : byte[]
Protect(string plaintext, DateTimeOffset expiration) : string
Protect(string plaintext, TimeSpan lifetime) : string
Protect(string plaintext) : string

ITimeLimitedDataProtector fournit plusieurs méthodes surchargées pour définir les méthodes de chiffrement avec des cycles de vie, les utilisateurs peuvent définir l'heure via Date TimeOffset, TimeSpan et autres paramètres

Il existe des méthodes de cryptage correspondantes, et les étudiants intéressés peuvent y consulter la documentation officielle

Configuration de la protection des données
<.>

在我们的 ASP.NET Core 运行的时候，系统会基于当前机器的运行环境默认配置一些关于 Data Protection 的东西，但是有些时候可能需要对这些配置做一些改变，比如在分布式部署的时候，在上一篇博文的末尾也提到过，下面就来看一下具体怎么配置的吧。 

上篇文章已经提到过，我们通过以下方式来把 Data Protection 注册到服务中：

public void ConfigureServices(IServiceCollection services)
{
 services.AddDataProtection();
}

   

其中AddDataProtection 返回的是一个 IDataProtectionBuilder 接口，这个接口提供了一个扩展方法PersistKeysToFileSystem() 来存储私钥。可以通过它传入一个路径来指定私钥存储的位置：

public void ConfigureServices(IServiceCollection services)
{
 services.AddDataProtection()
  .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));
 
}

   

可以传入一个共享文件夹，来存储私钥，这样在不同机器的私钥就可以保存到一个位置了。可以通过此种方式在分布式部署的时候，隔离开了机器的差异化。
 如果你觉得不安全，还可以配置一个X.509证书来，进行加密：

public void ConfigureServices(IServiceCollection services)
{
 services.AddDataProtection()
  .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
  .ProtectKeysWithCertificate("thumbprint");
}

   

上篇文章讲过，Data Protection 的默认保存时间是90天，你可以通过以下方式来修改默认的保存时间：

public void ConfigureServices(IServiceCollection services)
{
 services.AddDataProtection()
  .SetDefaultKeyLifetime(TimeSpan.FromDays(14));
}

   

默认情况下，即使使用相同的物理密钥库，Data Protection 也会把不同的应用程序隔离开，因为这样可以防止从一个应用程序获取另外一个应用程序的密钥。所以如果是相同的应用程序，可以设置相同的应用程序名称:

public void ConfigureServices(IServiceCollection services)
{
 services.AddDataProtection()
  .SetApplicationName("my application");
}

   

有时候需要禁用应用程序生成密钥，或者是说我只有一个程序用来生成或者管理密钥，其他程序只是负责读的话，那么可以这样：

 
public void ConfigureServices(IServiceCollection services)
{
 services.AddDataProtection()
  .DisableAutomaticKeyGeneration();
}

   

修改加密算法 

可以使用UseCryptographicAlgorithms方法来修改ASP.NET Core Data Protection的默认加密算法，如下：

services.AddDataProtection()
.UseCryptographicAlgorithms(new AuthenticatedEncryptionSettings()
{
 EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC,
 ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
});

   

总结：

本篇主要是介绍了一些常用的API， 下篇介绍一些高级的用法。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持PHP中文网。

更多ASP.NET Core 数据保护（Data Protection）相关文章请关注PHP中文网！