Est-ce une bonne pratique de définir des chaînes de connexion dans une configuration Web?

Récemment, j'ai eu une discussion avec certains de mes collègues à mon travail parce qu'ils ont dit qu'il valait mieux avoir dans un .DLL une connexion de chaîne cryptée. Et j'ai dit pourquoi n'utilisez pas la connexion de chaîne définie dans le web.config crypté? c'est la même chose et c'est mieux car le framework d'entité, par exemple cherche le nom de la connexion dans la configuration web de l'application, maintenant je veux savoir d'un point de sécurité quoi de mieux ou quelle est la meilleure pratique ??

Il n'y a pas de différence de fond, sauf que vous devrez réellement créer un binaire si vous souhaitez apporter une modification de configuration si vous le placez dans une DLL, tandis qu'un administrateur peut simplement modifier la configuration avec des outils standard bien connus si c'est dans la config. Il existe déjà un mécanisme de cryptage des chaînes de configuration et des conseils supplémentaires sur MSDN . Les versions actuelles d'Asp.Net peuvent avoir des mécanismes alternatifs, alors faites des recherches supplémentaires avant de vous engager dans une approche.

Le fait que quelque chose se trouve dans une DLL ne le rend pas plus sûr. Un éditeur de texte peut également ouvrir des fichiers binaires, des outils comme Reflector peuvent fournir une interface plus agréable pour naviguer dans une DLL .Net; une DLL ne fournira aucun chiffrement "supplémentaire".

Peu importe où les données chiffrées sont stockées, il importe comment elles sont chiffrées.

Les sections chiffrées d'un web.config sont normalement chiffrées avec l' API Data Protection , qui est extrêmement difficile à déchiffrer sans compromettre la machine entière. Vous pouvez également utiliser un conteneur de clés RSA, qui est similaire (difficile à retirer de la machine).

Si vous voulez stocker la chaîne cryptée dans la DLL, c'est bien, je suppose, bien que ce ne soit pas intrinsèquement plus sûr qu'un web.config crypté (n'importe qui peut jeter un œil dans cette DLL avec Reflector ), et est évidemment plus difficile à changer (vous aurait besoin de recompiler). Mais encore une fois, ce qui est beaucoup plus important, c'est la façon dont cette chaîne cryptée a été générée; je suppose que vous n'utilisez pas les mêmes fournisseurs que vous le feriez pour un fichier web.config crypté, alors qu'utilisez-vous?

Un schéma de chiffrement n'est aussi solide que la clé privée ou le secret partagé. Si cette clé est également stockée dans votre assembly, vous pourriez tout aussi bien ne pas avoir de chiffrement du tout. S'il est stocké dans une base de données externe, cela soulève la question de savoir comment la chaîne de connexion de cette base de données est sécurisée. Cela ne peut que conduire à une sécurité globale plus faible.

D'un autre côté, si vous étiez un fournisseur de services et que la chaîne de connexion était chiffrée avec un mot de passe utilisateur , cela serait plus sûr que d'utiliser une clé machine statique. Là encore, si vous utilisez des mots de passe utilisateur pour chiffrer, il est peu probable que vous codiez en dur les données chiffrées dans votre assemblage, car elles doivent être générées et stockées en réponse à l'action de l'utilisateur (pas du développeur).

Vraiment, je ne peux pas penser à trop de situations où le codage en dur d'une chaîne de connexion (cryptée) dans la DLL est plus sûr que le cryptage de la section web.config correspondante. Au mieux, cela ne fait qu'ajouter des inconvénients, au pire, il s'appuie sur une sécurité personnalisée maladroitement écrite criblée de trous. Rendez-vous service et faites ce que Microsoft recommande - cryptez simplement votre web.config s'il y a des données sensibles dedans.

La meilleure pratique pour ASP.NET est de placer toutes les configurations / paramètres dans le fichier web.config ou le fichier app.config (pour les autres types de projets).

Le cryptage et la raison de son utilisation sur vos chaînes de connexion doivent être un cas très spécial. Parce que la plupart des cas jusqu'à 99%, vous n'avez pas besoin de crypter vos chaînes de connexion. Les applications d'entreprise propres à Microsoft ont leur chaîne de connexion exposée dans le fichier web.config / app.config. Je pense que vous compliquez trop la sécurité.

Encore une chose, coder en dur vos chaînes de connexion est une mauvaise pratique. Par exemple, ne placez aucune chaîne de connexion (ou chaîne de connexion) dans une DLL ou .aspx / .ascx / .cshtml ou code-behind.