Partager via

Protection des chaînes de connexion et d’autres informations de configuration (VB)

  • Article

par Scott Mitchell

Télécharger le PDF

Une application ASP.NET stocke généralement les informations de configuration dans un fichier Web.config. Certaines de ces informations sont sensibles et justifient une protection. Par défaut, ce fichier ne sera pas fourni à un visiteur du site Web, mais un administrateur ou un pirate peut accéder au système de fichiers du serveur web et afficher le contenu du fichier. Dans ce tutoriel, nous apprenons que ASP.NET 2.0 nous permet de protéger les informations sensibles en chiffrant des sections du fichier Web.config.

Introduction

Les informations de configuration des applications ASP.NET sont généralement stockées dans un fichier XML nommé Web.config. Au cours de ces tutoriels, nous avons mis à jour les Web.config quelques fois. Lors de la création du Northwind DataSet typé dans le premier tutoriel, par exemple, chaîne de connexion informations ont été automatiquement ajoutées à Web.config la <connectionStrings> section. Plus tard, dans le tutoriel Pages maîtres et navigation de site , nous avons mis à jour Web.configmanuellement , ajoutant un <pages> élément indiquant que toutes les pages ASP.NET de notre projet doivent utiliser le DataWebControls thème.

Étant donné Web.config que peut contenir des données sensibles telles que des chaînes de connexion, il est important que le contenu de Web.config soit conservé en sécurité et masqué aux visionneuses non autorisées. Par défaut, toute requête HTTP adressée à un fichier avec l’extension .config est gérée par le moteur ASP.NET, qui retourne le message Ce type de page n’est pas servi comme illustré dans la figure 1. Cela signifie que les visiteurs ne peuvent pas afficher le contenu de votre Web.config fichier en entrant http://www.YourServer.com/Web.config simplement dans la barre d’adresse de leur navigateur.

La visite Web.config par le biais d’un navigateur retourne un message Ce type de page n’est pas servi

Figure 1 : La visite Web.config par le biais d’un navigateur renvoie un message Ce type de page n’est pas servi (Cliquez pour afficher l’image en taille réelle)

Mais que se passe-t-il si un attaquant est en mesure de trouver un autre exploit qui lui permet d’afficher le contenu de votre Web.config fichier ? Que peut faire un attaquant avec ces informations et quelles mesures peuvent être prises pour mieux protéger les informations sensibles dans Web.config? Heureusement, la plupart des sections de Web.config ne contiennent pas d’informations sensibles. Quels dommages un attaquant peut-il perpétrer s’il connaît le nom du thème par défaut utilisé par vos pages ASP.NET ?

Certaines Web.config sections, toutefois, contiennent des informations sensibles qui peuvent inclure des chaînes de connexion, des noms d’utilisateur, des mots de passe, des noms de serveur, des clés de chiffrement, etc. Ces informations se trouvent généralement dans les sections suivantes Web.config :

  • <appSettings>
  • <connectionStrings>
  • <identity>
  • <sessionState>

Dans ce tutoriel, nous allons examiner les techniques de protection de ces informations de configuration sensibles. Comme nous allons le voir, .NET Framework version 2.0 inclut un système de configurations protégées qui facilite le chiffrement et le déchiffrement programmatiquement des sections de configuration sélectionnées.

Notes

Ce tutoriel se termine par un aperçu des recommandations de Microsoft pour la connexion à une base de données à partir d’une application ASP.NET. En plus de chiffrer vos chaînes de connexion, vous pouvez renforcer votre système en vous assurant que vous vous connectez à la base de données de manière sécurisée.

Étape 1 : Exploration des options de configuration protégées de ASP.NET 2.0 s

ASP.NET 2.0 inclut un système de configuration protégé pour le chiffrement et le déchiffrement des informations de configuration. Cela inclut les méthodes du .NET Framework qui peuvent être utilisées pour chiffrer ou déchiffrer par programmation les informations de configuration. Le système de configuration protégé utilise le modèle de fournisseur qui permet aux développeurs de choisir l’implémentation de chiffrement utilisée.

Le .NET Framework est fourni avec deux fournisseurs de configuration protégés :

Étant donné que le système de configuration protégé implémente le modèle de conception du fournisseur, il est possible de créer votre propre fournisseur de configuration protégé et de le connecter à votre application. Pour plus d’informations sur ce processus, consultez Implémentation d’un fournisseur de configuration protégé .

Les fournisseurs RSA et DPAPI utilisent des clés pour leurs routines de chiffrement et de déchiffrement, et ces clés peuvent être stockées au niveau de l’ordinateur ou de l’utilisateur. Les clés au niveau de l’ordinateur sont idéales pour les scénarios où l’application web s’exécute sur son propre serveur dédié ou s’il existe plusieurs applications sur un serveur qui doivent partager des informations chiffrées. Les clés de niveau utilisateur sont une option plus sécurisée dans les environnements d’hébergement partagé où d’autres applications sur le même serveur ne doivent pas être en mesure de déchiffrer les sections de configuration protégées de votre application.

Dans ce tutoriel, nos exemples utilisent le fournisseur DPAPI et les clés au niveau de l’ordinateur. Plus précisément, nous allons examiner le chiffrement de la <connectionStrings> section dans Web.config, bien que le système de configuration protégé puisse être utilisé pour chiffrer la plupart des Web.config sections. Pour plus d’informations sur l’utilisation de clés de niveau utilisateur ou sur l’utilisation du fournisseur RSA, consultez les ressources de la section Lectures supplémentaires à la fin de ce tutoriel.

Notes

Les RSAProtectedConfigurationProvider fournisseurs et DPAPIProtectedConfigurationProvider sont inscrits dans le machine.config fichier avec les noms RsaProtectedConfigurationProvider de fournisseur et DataProtectionConfigurationProvider, respectivement. Lors du chiffrement ou du déchiffrement des informations de configuration, nous devrons fournir le nom de fournisseur approprié (RsaProtectedConfigurationProvider ou DataProtectionConfigurationProvider) plutôt que le nom de type réel (RSAProtectedConfigurationProvider et DPAPIProtectedConfigurationProvider). Vous trouverez le machine.config fichier dans le $WINDOWS$\Microsoft.NET\Framework\version\CONFIG dossier .

Étape 2 : Sections de configuration de chiffrement et de déchiffrement par programmation

Avec quelques lignes de code, nous pouvons chiffrer ou déchiffrer une section de configuration particulière à l’aide d’un fournisseur spécifié. Comme nous le verrons bientôt, le code doit simplement référencer par programmation la section de configuration appropriée, appeler sa ProtectSection méthode ou UnprotectSection , puis appeler la Save méthode pour conserver les modifications. En outre, le .NET Framework inclut un utilitaire de ligne de commande utile qui peut chiffrer et déchiffrer les informations de configuration. Nous allons explorer cet utilitaire de ligne de commande à l’étape 3.

Pour illustrer la protection programmatique des informations de configuration, créons une page ASP.NET qui inclut des boutons pour chiffrer et déchiffrer la <connectionStrings> section dans Web.config.

Commencez par ouvrir la EncryptingConfigSections.aspx page dans le AdvancedDAL dossier. Faites glisser un contrôle TextBox de la boîte à outils vers le Designer, affectant à WebConfigContentssa ID propriété la valeur , sa TextMode propriété à MultiLineet ses Width propriétés sur Rows 95 % et 15, respectivement. Ce contrôle TextBox affiche le contenu de nous permettant de Web.config voir rapidement si le contenu est chiffré ou non. Bien sûr, dans une application réelle, vous ne voudriez jamais afficher le contenu de Web.config.

Sous textBox, ajoutez deux contrôles Button nommés EncryptConnStrings et DecryptConnStrings. Définissez leurs propriétés Text sur Chiffrer les chaînes de connexion et Déchiffrer les chaînes de connexion .

À ce stade, votre écran doit ressembler à la figure 2.

Capture d’écran montrant Visual Studio ouvert à la page EncryptingConfigSections.aspx, qui a un nouveau contrôle TextBox et deux contrôles Button.

Figure 2 : Ajouter un contrôle Web TextBox et deux boutons à la page (cliquez pour afficher l’image en taille réelle)

Ensuite, nous devons écrire du code qui charge et affiche le contenu de dans la WebConfigContents zone de texte lors du premier chargement de Web.config la page. Ajoutez le code suivant à la classe code-behind de la page. Ce code ajoute une méthode nommée DisplayWebConfig et l’appelle à partir du Page_Load gestionnaire d’événements quand Page.IsPostBack est False:

Protected Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load
    'On the first page visit, call DisplayWebConfig method
    If Not Page.IsPostBack Then
        DisplayWebConfig()
    End If
End Sub
Private Sub DisplayWebConfig()
    'Reads in the contents of Web.config and displays them in the TextBox
    Dim webConfigStream As StreamReader = _
        File.OpenText(Path.Combine(Request.PhysicalApplicationPath, "Web.config"))
    Dim configContents As String = webConfigStream.ReadToEnd()
    webConfigStream.Close()
    WebConfigContents.Text = configContents
End Sub

La DisplayWebConfig méthode utilise la File classe pour ouvrir le fichier s de l’application Web.config , la StreamReader classe pour lire son contenu dans une chaîne et la Path classe pour générer le chemin physique du Web.config fichier. Ces trois classes se trouvent toutes dans l’espace deSystem.IO noms. Par conséquent, vous devez ajouter une Imports``System.IO instruction en haut de la classe code-behind ou, sinon, préfixer ces noms de classe avec System.IO.

Ensuite, nous devons ajouter des gestionnaires d’événements pour les deux événements de contrôles Click Button et ajouter le code nécessaire pour chiffrer et déchiffrer la section à l’aide d’une clé au niveau de l’ordinateur <connectionStrings> avec le fournisseur DPAPI. À partir du Designer, double-cliquez sur chacun des boutons pour ajouter un gestionnaire d’événements Click dans la classe code-behind, puis ajoutez le code suivant :

Protected Sub EncryptConnStrings_Click(sender As Object, e As EventArgs) _
    Handles EncryptConnStrings.Click
    'Get configuration information about Web.config
    Dim config As Configuration = _
        WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath)
    ' Let's work with the <connectionStrings> section
    Dim connectionStrings As ConfigurationSection = _
        config.GetSection("connectionStrings")
    If connectionStrings IsNot Nothing Then
        ' Only encrypt the section if it is not already protected
        If Not connectionStrings.SectionInformation.IsProtected Then
            ' Encrypt the <connectionStrings> section using the 
            ' DataProtectionConfigurationProvider provider
            connectionStrings.SectionInformation.ProtectSection( _
                "DataProtectionConfigurationProvider")
            config.Save()
            ' Refresh the Web.config display
            DisplayWebConfig()
        End If
    End If
End Sub
Protected Sub DecryptConnStrings_Click(sender As Object, e As EventArgs) _
    Handles DecryptConnStrings.Click
    ' Get configuration information about Web.config
    Dim config As Configuration = _
        WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath)
    ' Let's work with the <connectionStrings> section
    Dim connectionStrings As ConfigurationSection = _
        config.GetSection("connectionStrings")
    If connectionStrings IsNot Nothing Then
        ' Only decrypt the section if it is protected
        If connectionStrings.SectionInformation.IsProtected Then
            ' Decrypt the <connectionStrings> section
            connectionStrings.SectionInformation.UnprotectSection()
            config.Save()
            ' Refresh the Web.config display
            DisplayWebConfig()
        End If
    End If
End Sub

Le code utilisé dans les deux gestionnaires d’événements est presque identique. Ils commencent tous deux par obtenir des informations sur le fichier s d’application Web.config actuel via la WebConfigurationManager méthode class sOpenWebConfiguration. Cette méthode retourne le fichier de configuration web pour le chemin d’accès virtuel spécifié. Ensuite, la Web.config section s du <connectionStrings> fichier est accessible via la Configuration méthode class sGetSection(sectionName), qui retourne un ConfigurationSection objet.

L’objet ConfigurationSection inclut une SectionInformation propriété qui fournit des informations et des fonctionnalités supplémentaires concernant la section de configuration. Comme le montre le code ci-dessus, nous pouvons déterminer si la section de configuration est chiffrée en vérifiant la SectionInformation propriété s IsProtected . De plus, la section peut être chiffrée ou déchiffrée via les méthodes et UnprotectSection les SectionInformationProtectSection(provider) propriétés.

La ProtectSection(provider) méthode accepte comme entrée une chaîne spécifiant le nom du fournisseur de configuration protégé à utiliser lors du chiffrement. Dans le EncryptConnString gestionnaire d’événements Button, nous transmettons DataProtectionConfigurationProvider à la ProtectSection(provider) méthode afin que le fournisseur DPAPI soit utilisé. La UnprotectSection méthode peut déterminer le fournisseur qui a été utilisé pour chiffrer la section de configuration et ne nécessite donc aucun paramètre d’entrée.

Après avoir appelé la ProtectSection(provider) méthode ouUnprotectSection, vous devez appeler la méthode de l’objet Configuration pour Save conserver les modifications. Une fois les informations de configuration chiffrées ou déchiffrées et les modifications enregistrées, nous appelons DisplayWebConfig pour charger le contenu mis à jour Web.config dans le contrôle TextBox.

Une fois que vous avez entré le code ci-dessus, testez-le en visitant la EncryptingConfigSections.aspx page via un navigateur. Vous devez d’abord voir une page qui répertorie le contenu de Web.config avec la <connectionStrings> section affichée en texte brut (voir figure 3).

Capture d’écran montrant la page EncryptingConfigSections.aspx chargée dans un navigateur web.

Figure 3 : Ajouter un contrôle Web TextBox et deux boutons à la page (cliquer pour afficher l’image en taille réelle)

Cliquez maintenant sur le bouton Chiffrer les chaînes de connexion. Si la validation de la demande est activée, le balisage publié à partir de TextBox WebConfigContents génère un HttpRequestValidationExceptionmessage , qui affiche le message : Une valeur potentiellement dangereuse Request.Form a été détectée à partir du client. La validation des demandes, qui est activée par défaut dans ASP.NET 2.0, interdit les publications qui incluent du code HTML non codé et est conçue pour empêcher les attaques par injection de script. Cette case activée peut être désactivée au niveau de la page ou de l’application. Pour le désactiver pour cette page, définissez le ValidateRequest paramètre sur False dans la @Page directive. La @Page directive se trouve en haut du balisage déclaratif de la page.

<%@ Page ValidateRequest="False" ... %>

Pour plus d’informations sur la validation des demandes, son objectif, la façon de la désactiver au niveau de la page et de l’application, ainsi que sur l’encodage HTML du balisage, consultez Validation des demandes - Prévention des attaques de script.

Après avoir désactivé la validation des demandes pour la page, essayez de cliquer à nouveau sur le bouton Chiffrer les chaînes de connexion. Lors de la publication, le fichier de configuration est accessible et sa <connectionStrings> section chiffrée à l’aide du fournisseur DPAPI. Le contrôle TextBox est ensuite mis à jour pour afficher le nouveau Web.config contenu. Comme le montre la figure 4, les <connectionStrings> informations sont désormais chiffrées.

Cliquer sur le bouton Chiffrer les chaînes de connexion chiffre la <section connectionString>

Figure 4 : Cliquer sur le bouton Chiffrer les chaînes de connexion chiffre la <connectionString> section (Cliquer pour afficher l’image de taille réelle)

La section chiffrée <connectionStrings> générée sur mon ordinateur suit, bien qu’une partie du contenu de l’élément <CipherData> ait été supprimée par souci de concision :

<connectionStrings 
    configProtectionProvider="DataProtectionConfigurationProvider">
  <EncryptedData>
    <CipherData>
      <CipherValue>AQAAANCMnd8BFdERjHoAwE/...zChw==</CipherValue>
    </CipherData>
  </EncryptedData>
</connectionStrings>

Notes

L’élément <connectionStrings> spécifie le fournisseur utilisé pour effectuer le chiffrement (DataProtectionConfigurationProvider). Ces informations sont utilisées par la UnprotectSection méthode lorsque l’utilisateur clique sur le bouton Déchiffrer les chaînes de connexion.

Lorsque les informations chaîne de connexion sont accessibles à partir du Web.config code que nous écrivons, à partir d’un contrôle SqlDataSource ou du code généré automatiquement à partir des TableAdapters dans nos DataSets typés, elles sont automatiquement déchiffrées. En bref, nous n’avons pas besoin d’ajouter de code ou de logique supplémentaire pour déchiffrer la section chiffrée <connectionString> . Pour illustrer cela, consultez l’un des didacticiels précédents à l’heure actuelle, tel que le didacticiel Affichage simple de la section Rapports de base (~/BasicReporting/SimpleDisplay.aspx). Comme le montre la figure 5, le didacticiel fonctionne exactement comme prévu, indiquant que les informations chiffrées chaîne de connexion sont automatiquement déchiffrées par la page ASP.NET.

La couche d’accès aux données déchiffre automatiquement les informations de chaîne de connexion

Figure 5 : La couche d’accès aux données déchiffre automatiquement les informations de chaîne de connexion (cliquez pour afficher l’image en taille réelle)

Pour rétablir la représentation en texte brut de la <connectionStrings> section, cliquez sur le bouton Déchiffrer les chaînes de connexion. Dans la publication, vous devez voir les chaînes de connexion dans Web.config en texte brut. À ce stade, votre écran doit ressembler à celui qu’il a fait lors de la première visite de cette page (voir figure 3).

Étape 3 : Chiffrement des sections de configuration à l’aide de aspnet_regiis.exe

Le .NET Framework inclut divers outils en ligne de commande dans le $WINDOWS$\Microsoft.NET\Framework\version\ dossier . Dans le didacticiel Utilisation des dépendances du cache SQL, pour instance, nous avons examiné l’utilisation de l’outil aspnet_regsql.exe en ligne de commande pour ajouter l’infrastructure nécessaire pour les dépendances de cache SQL. Un autre outil en ligne de commande utile dans ce dossier est l’outil d’inscription IIS ASP.NET (aspnet_regiis.exe). Comme son nom l’indique, l’outil d’inscription IIS ASP.NET est principalement utilisé pour inscrire une application ASP.NET 2.0 auprès du serveur Web de qualité professionnelle de Microsoft, IIS. En plus de ses fonctionnalités liées à IIS, l’outil d’inscription IIS ASP.NET peut également être utilisé pour chiffrer ou déchiffrer les sections de configuration spécifiées dans Web.config.

L’instruction suivante montre la syntaxe générale utilisée pour chiffrer une section de configuration avec l’outil aspnet_regiis.exe en ligne de commande :

aspnet_regiis.exe -pef section physical_directory -prov provider

section est la section de configuration à chiffrer (comme connectionStrings), la physical_directory est le chemin d’accès physique complet au répertoire racine de l’application web, et le fournisseur est le nom du fournisseur de configuration protégé à utiliser (par exemple, DataProtectionConfigurationProvider). Si l’application web est inscrite dans IIS, vous pouvez également entrer le chemin d’accès virtuel au lieu du chemin physique à l’aide de la syntaxe suivante :

aspnet_regiis.exe -pe section -app virtual_directory -prov provider

L’exemple suivant aspnet_regiis.exe chiffre la section à l’aide <connectionStrings> du fournisseur DPAPI avec une clé au niveau de l’ordinateur :

aspnet_regiis.exe -pef
"connectionStrings" "C:\Websites\ASPNET_Data_Tutorial_73_VB"
-prov "DataProtectionConfigurationProvider"

De même, l’outil aspnet_regiis.exe en ligne de commande peut être utilisé pour déchiffrer les sections de configuration. Au lieu d’utiliser le -pef commutateur, utilisez -pdf (ou à la place de -pe, utilisez -pd). Notez également que le nom du fournisseur n’est pas nécessaire lors du déchiffrement.

aspnet_regiis.exe -pdf section physical_directory
  -- or --
aspnet_regiis.exe -pd section -app virtual_directory

Notes

Étant donné que nous utilisons le fournisseur DPAPI, qui utilise des clés spécifiques à l’ordinateur, vous devez exécuter aspnet_regiis.exe à partir de l’ordinateur à partir duquel les pages web sont traitées. Par exemple, si vous exécutez ce programme en ligne de commande à partir de votre ordinateur de développement local, puis que vous chargez le fichier de Web.config chiffré sur le serveur de production, le serveur de production ne pourra pas déchiffrer les informations de chaîne de connexion, car elles ont été chiffrées à l’aide de clés spécifiques à votre ordinateur de développement. Le fournisseur RSA n’a pas cette limitation, car il est possible d’exporter les clés RSA vers un autre ordinateur.

Présentation des options d’authentification de base de données

Avant qu’une application puisse émettre SELECTdes requêtes , INSERT, UPDATEou DELETE sur une base de données Microsoft SQL Server, la base de données doit d’abord identifier le demandeur. Ce processus est appelé authentification et SQL Server fournit deux méthodes d’authentification :

  • Authentification Windows : le processus sous lequel l’application s’exécute est utilisé pour communiquer avec la base de données. Lors de l’exécution d’une application ASP.NET via Visual Studio 2005 s ASP.NET Development Server, l’application ASP.NET suppose l’identité de l’utilisateur actuellement connecté. Pour ASP.NET applications sur Microsoft Internet Information Server (IIS), ASP.NET applications supposent généralement l’identité de domainName``\MachineName ou domainName``\NETWORK SERVICE, bien que cela puisse être personnalisé.
  • Authentification SQL : des valeurs d’ID utilisateur et de mot de passe sont fournies comme informations d’identification pour l’authentification. Avec l’authentification SQL, l’ID utilisateur et le mot de passe sont fournis dans le chaîne de connexion.

Authentification Windows est préférable à l’authentification SQL, car elle est plus sécurisée. Avec Authentification Windows le chaîne de connexion est libre d’un nom d’utilisateur et d’un mot de passe et si le serveur web et le serveur de base de données résident sur deux ordinateurs différents, les informations d’identification ne sont pas envoyées sur le réseau en texte brut. Avec l’authentification SQL, toutefois, les informations d’identification d’authentification sont codées en dur dans le chaîne de connexion et sont transmises du serveur web au serveur de base de données en texte brut.

Ces tutoriels ont utilisé Authentification Windows. Vous pouvez déterminer le mode d’authentification utilisé en inspectant les chaîne de connexion. Les chaîne de connexion de Web.config nos tutoriels ont été les suivants :

Data Source=.\SQLEXPRESS; AttachDbFilename=|DataDirectory|\NORTHWND.MDF; Integrated Security=True; User Instance=True

La valeur Integrated Security=True et l’absence de nom d’utilisateur et de mot de passe indiquent que Authentification Windows est utilisée. Dans certaines chaînes de connexion, le terme Trusted Connection=Yes ou Integrated Security=SSPI est utilisé au lieu d’Integrated Security=True, mais les trois indiquent l’utilisation de Authentification Windows.

L’exemple suivant montre une chaîne de connexion qui utilise l’authentification SQL. Notez les informations d’identification incorporées dans le chaîne de connexion :

Server=serverName; Database=Northwind; uid=userID; pwd=password

Imaginez qu’un attaquant soit en mesure d’afficher le fichier de Web.config votre application. Si vous utilisez l’authentification SQL pour vous connecter à une base de données accessible via Internet, l’attaquant peut utiliser cette chaîne de connexion pour se connecter à votre base de données via SQL Management Studio ou à partir de pages ASP.NET sur son propre site web. Pour atténuer cette menace, chiffrez les informations chaîne de connexion à Web.config l’aide du système de configuration protégé.

Notes

Pour plus d’informations sur les différents types d’authentification disponibles dans SQL Server, consultez Génération d’applications ASP.NET sécurisées : authentification, autorisation et communication sécurisée. Pour obtenir d’autres exemples de chaîne de connexion illustrant les différences entre la syntaxe d’authentification Windows et SQL, reportez-vous à ConnectionStrings.com.

Résumé

Par défaut, les fichiers avec une .config extension dans une application ASP.NET ne sont pas accessibles via un navigateur. Ces types de fichiers ne sont pas retournés, car ils peuvent contenir des informations sensibles, telles que des chaînes de connexion de base de données, des noms d’utilisateur et des mots de passe, etc. Le système de configuration protégé dans .NET 2.0 permet de mieux protéger les informations sensibles en autorisant le chiffrement des sections de configuration spécifiées. Il existe deux fournisseurs de configuration protégés intégrés : un qui utilise l’algorithme RSA et l’autre qui utilise l’API de protection des données Windows (DPAPI).

Dans ce tutoriel, nous avons examiné comment chiffrer et déchiffrer les paramètres de configuration à l’aide du fournisseur DPAPI. Cela peut être accompli à la fois par programmation, comme nous l’avons vu à l’étape 2, ainsi que par le biais de l’outil aspnet_regiis.exe en ligne de commande, qui a été abordé à l’étape 3. Pour plus d’informations sur l’utilisation de clés au niveau de l’utilisateur ou sur l’utilisation du fournisseur RSA à la place, consultez les ressources de la section Lecture supplémentaire.

Bonne programmation !

En savoir plus

Pour plus d’informations sur les sujets abordés dans ce didacticiel, consultez les ressources suivantes :

À propos de l’auteur

Scott Mitchell, auteur de sept livres ASP/ASP.NET et fondateur de 4GuysFromRolla.com, travaille avec les technologies Web Microsoft depuis 1998. Scott travaille comme consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Il est accessible à l’adressemitchell@4GuysFromRolla.com . ou via son blog, qui se trouve à l’adresse http://ScottOnWriting.NET.

Remerciements spéciaux à

Cette série de tutoriels a été examinée par de nombreux réviseurs utiles. Les principaux réviseurs de ce tutoriel étaient Teresa Murphy et Randy Schmidt. Vous souhaitez consulter mes prochains articles MSDN ? Si c’est le cas, déposez-moi une ligne à mitchell@4GuysFromRolla.com.

PrécédentSuivant