Vous avez ici un nombre limité d'approches pour garder votre chaîne de connexion en toute sécurité. Une option, si votre chaîne de connexion est stockée dans un fichier web.config ou app.config (respectivement pour les applications Web et Windows), vous pouvez crypter la valeur. Voici quelques liens qui détaillent comment cela peut se faire:
Encrypting Web.Config Values in ASP.NET 2.0
Encrypt Connection Strings in VS 2005 .config Files
Bien sûr, comme vous le dites très justement, cela peut ne pas atteindre la sécurité que vous désirez, puisque l'application peut bien fonctionner sur la machine de l'utilisateur, et donc le fichier app.config (même dans un état crypté) et les clés de cryptage/décryptage associées seront également disponibles sur la machine de l'utilisateur. Un utilisateur averti et entreprenant pourrait alors avoir accès à votre chaîne de connexion «texte brut». À mon humble avis, l'une des meilleures façons d'empêcher vos utilisateurs de voir votre chaîne de connexion à la base de données est de ne jamais la leur donner en premier lieu, cryptée ou non. Cela nécessiterait que votre application de formulaires Windows ne parle pas directement à une base de données (en utilisant une chaîne de connexion), mais parle plutôt directement à (par exemple) un service Web. Bien sûr, vous donneriez à l'application de formulaire Windows une URL avec laquelle elle pourrait accéder au service Web, mais l'utilisation de ce service Web serait restreinte et contrôlée en autorisant uniquement l'accès avec une combinaison nom d'utilisateur/mot de passe spécifique à l'utilisateur. .
De cette façon, vous pouvez héberger le service Web (ne doit pas être un web service - il pourrait être une application distante que la demande de vos fenêtres de forme communiquerait avec plus .NET remoting ou WCF) sur un serveur séparé physiquement/machine vous avez un contrôle complet sur et protéger cette machine avec perimeter security. Ce sont les applications et les services que vous avez exécutés sur cette machine sécurisée qui ont accès à la chaîne de connexion de la base de données, et cette chaîne de connexion n'a jamais besoin d'être divulguée en dehors du périmètre de cette machine. en supposant que la sécurité du périmètre susmentionnée est en place et est efficace). Bien sûr, la mise en œuvre de tout cela impliquerait certainement d'énormes changements architecturaux à votre application, ce qui, selon la taille et la nature de votre application, peut ou non être utile, cependant, la seule façon de vraiment sécuriser votre application. La chaîne de connexion d'un utilisateur (ou la machine d'un utilisateur) est de s'assurer qu'il n'est jamais disponible (sous forme cryptée ou décryptée) à l'utilisateur (ou à la machine de l'utilisateur).Dès que vous mettez la chaîne de connexion sur la machine de l'utilisateur, même dans un état crypté, vous devez donner à cette même machine la capacité de décrypter cette chaîne de connexion cryptée, et il y a le maillon faible dans la chaîne et le point auquel (pour un utilisateur débrouillard) votre chaîne de connexion en texte brut peut être déterminée. Vous pouvez décharger le déchiffrement de la chaîne de connexion cryptée sur une autre machine (sécurisée), mais il s'agit simplement d'une variante du mécanisme client-serveur mentionné précédemment dans lequel la partie sécurisée (clé de déchiffrement, chaîne de connexion, etc.) est exécutée sur une machine différente sous votre propre contrôle sécurisé.
Votre application peut-elle déchiffrer les hachages? – yfeldblum