Quelle est la meilleure façon de stocker la chaîne de connexion dans les DLL .NET ?

Question

L'application que mon équipe développe actuellement possède une DLL qui est utilisée pour effectuer tous les accès à la base de données.L'application ne peut pas utiliser une connexion approuvée car la base de données se trouve derrière un pare-feu et le serveur de domaine ne l'est pas.Il semble donc que la chaîne de connexion doit avoir un nom d'utilisateur et un mot de passe DB.La DLL a actuellement la chaîne de connexion à la base de données codée en dur, mais je ne veux pas faire cela lors du lancement car l'assemblage peut être démonté et le nom d'utilisateur et le mot de passe seraient là à l'air libre.

L'une des exigences est que le mot de passe doit être changé tous les quelques mois, nous devrons donc le déployer auprès de notre base d'utilisateurs internes.

Existe-t-il un moyen de stocker le mot de passe crypté de manière à ce que nous puissions facilement le distribuer à l'ensemble de la base d'utilisateurs sans le stocker dans l'assembly ?

MISE À JOUR:Merci à tous ceux qui ont répondu.Je vais essayer de répondre à certaines questions...La DLL de données est utilisée à la fois par ASP.NET WebForms et VB.NET WinForms.Je comprends que les applications peuvent avoir leurs propres fichiers de configuration, mais je n'ai rien vu sur les fichiers de configuration des DLL.Malheureusement, je ne peux pas me rendre au poste de Jon Galloway au travail, donc je ne peux pas juger si cela fonctionnera.Du point de vue du développement, nous ne souhaitons pas utiliser de services Web en interne, mais nous pourrions les fournir à des tiers l'année prochaine.Je ne pense pas que l'usurpation d'identité fonctionnera car nous ne pouvons pas authentifier l'utilisateur via le pare-feu.Comme un utilisateur (ou ancien utilisateur) peut être un attaquant, nous le cachons à tout le monde !

Answer 1

Je ne suis pas sûr, mais je pense que vous pouvez le mettre dans un fichier de configuration et chiffrer le fichier de configuration.

Mise à jour:Voir le message de Jon Galloway ici.

Answer 2

Supposons simplement que les méchants obtiendront les informations d'identification de votre fichier de configuration.Cela signifie qu'ils pourront se connecter à votre base de données et faire tout ce dont cet utilisateur est capable.Assurez-vous donc simplement que l'utilisateur ne peut rien faire de mal, comme accéder directement aux tables.Rendez cet utilisateur uniquement capable d'exécuter certaines procédures stockées et vous serez en meilleure forme.C'est un endroit où les sprocs brillent.

Answer 3

Je déteste dire cela, mais dès que vous mettez quelque chose sur un ordinateur client, la sécurité de ces données disparaît.

Si votre programme veut déchiffrer cette chaîne, vous devez supposer qu'un attaquant peut faire de même.Attacher un débogueur à votre programme serait un moyen.

Stocker la chaîne de connexion sur un serveur et l'obtenir via une connexion Web semble bien, jusqu'à ce que vous réalisiez que vous avez également besoin de sécurité sur cette connexion Web, sinon un attaquant pourrait tout aussi bien usurper l'identité de votre programme et communiquer avec la connexion Web.

Permettez-moi de poser une question.À qui cachez-vous la chaîne de connexion ?L'utilisateur ou un attaquant ?Et si c'est l'utilisateur, pourquoi ?

Answer 4

Il y a aussi d'autres idées.Vous pouvez toujours utiliser l'usurpation d'identité.Vous pouvez également utiliser la bibliothèque d'entreprise (bibliothèque commune).

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Answer 5

.NET prend en charge le chiffrement sur les valeurs de configuration comme celle-ci.Vous pouvez le laisser dans un fichier de configuration, mais crypté.

Answer 6

Vous voulez pouvoir distribuer la DLL avec toutes les informations de configuration dans un endroit configurable, mais le fait est que vous ne pouvez pas avoir l'un des fichiers de configuration .NET très pratiques pour une DLL à moins que vous ne fassiez quelque chose de personnalisé.

Vous devez peut-être repenser la responsabilité que devrait avoir votre DLL.Serait-il possible, ou logique, d'exiger que la chaîne de connexion soit transmise par l'utilisateur de votre bibliothèque ?Est-il vraiment logique que votre DLL lise un fichier de configuration ?

Answer 7

Si l'application est une application ASP.NET, chiffrez simplement la section des chaînes de connexion de votre web.config.

Si l'application est une application client exécutée sur plusieurs machines, au lieu de stocker la chaîne de connexion localement, envisagez d'utiliser un service Web ou un autre type de mécanisme sécurisé pour la stocker de manière centralisée.Cela faciliterait les mises à jour plus faciles à l'avenir et vous ne stockez pas la chaîne de connexion localement.

Juste quelques réflexions.

Mis à jour: @lassevk

"Stocker la chaîne de connexion sur un serveur et l'obtenir via une connexion Web semble une bonne chose, jusqu'à ce que vous réalisiez que vous avez également besoin de sécurité sur cette connexion Web, sinon un attaquant pourrait tout aussi bien usurper l'identité de votre programme et communiquer avec la connexion Web. "

La sécurité du service Web était implicite.Selon le type de déploiement, il existe de nombreuses options... par exemple les certificats côté client.

Answer 8

Plusieurs options :

1. Stocker dans web.config et chiffrer
2. Stocker dans DLL et obscurcir (dotfuscator)
3. Stockez-en un dans web.config (crypté bien sûr) et reposez-le dans la base de données (si vous devez en utiliser plusieurs et que le cryptage/déchiffrement devient pénible)