2009-09-29 5 views
1

Comme tous les développeurs .net savent qu'il est possible de chiffrer les valeurs dans web.config.Question de sécurité intéressante pour les développeurs .net

J'ai d'autres fichiers de configuration XML, que j'ai lus à partir de techniques de sérialisation, n'utilisant pas system.configuration mais plutôt sérialisation à un objet fortement typé.

Il est maintenant devenu une exigence pour moi de crypter certaines valeurs dans ce fichier XML, pas tout le fichier XML, juste quelques valeurs de chaîne dans le fichier.

Tout cela serait assez standard, sauf que cette application va s'exécuter chez le client, et le client devrait pouvoir changer directement la configuration.

Donc. Comment puis-je configurer ce chiffrement de telle sorte que le client puisse générer des valeurs nouvellement cryptées dans le fichier de configuration, par exemple - une chaîne de connexion SQL. Jusqu'ici, la meilleure façon de penser est d'envoyer une application personnalisée, capable de chiffrer des valeurs, afin que mon application sache quoi faire avec ces valeurs de manière standardisée.

Quelqu'un peut-il améliorer cette idée?

Répondre

2

La majorité des applications que j'ai vues qui font exactement ce dont vous parlez utilisent la même solution que vous proposez.

Il existe un outil distinct pour administrer la configuration de l'application. C'est bruyant, mais c'est ce qu'il faut pour faire le travail.

Si vous parlez d'une application Web avec la configuration que n'est pas stockée dans le fichier web.config, vous pouvez créer l'interface d'administration dans l'application. De cette façon, votre application web peut gérer le cryptage et la configuration de votre application ressemble à celle de l'application elle-même (comme elle le devrait).

Je pense que l'un fonctionnerait ... le dernier est juste plus difficile à comprendre.

MISE À JOUR

Je viens de voir le commentaire que vous parlez d'une application de service Web. Dans ce cas, vous pourriez exposer des services spécifiquement utilisés pour configurer l'application de service (ce qui serait difficile à mettre en œuvre). Ou vous pouvez créer une petite application Web qui permet à un administrateur de configurer les services (plus facile à mettre en œuvre). Le dernier effort de fossé serait l'application WinForms (plus facile). Et aussi longtemps que votre service prend les champs dans un format non crypté, puis les crypte côté serveur avant de les stocker ... vous ne devriez pas avoir à vous soucier d'exposer des clés.

Si vous souhaitez leur permettre de demander des valeurs existantes, vos services doivent renvoyer les valeurs non cryptées. Une fois de plus, le décryptage se fait côté serveur, donc vous ne risquez pas d'exposer vos clés.

+0

+1 et accepté la réponse parce que (a) signifie que le client a moins de travail à faire (b) moins de risque d'attaque = gagnant/gagnant –

1

Si vous avez une section admin de votre application web, vous pouvez avoir le code qui génère la valeur cryptée ici, pas besoin d'une application winform.

+0

Ceci est une application de service Web, disons que j'expose un autre service Web pour retourner la chaîne de chiffrement. Pensez-vous qu'il pourrait potentiellement être utilisé pour l'ingénierie inverse de la clé privée? –

+0

J'utilise TripleDES pour cela, et je pense qu'il serait assez difficile d'inverser directement les résultats. Bien sûr, ils peuvent toujours tirer sur Reflector et voir ce que vous faites, auquel cas vous voudrez peut-être penser à faire cette partie de manière plus sûre. –

+0

Code est obfusqué, l'application est durcie vers le bas, donc ce serait le plus logique je suppose ... –

1

Nous utilisons une DLL personnalisée pour gérer le cryptage dans nos applications. Il pourrait en fait être intégré dans l'application elle-même, mais nous l'utilisons dans de nombreux projets différents, de sorte qu'il a été déplacé vers sa propre DLL. Nous incluons juste une référence et nous partons.Il suffit de se méfier du fait que si vous allez sur cette route, s'ils (les clients) le voulaient, ils pourraient désassembler la DLL et arriver à la façon dont vous effectuez le cryptage. Dans notre cas, ce risque nous convient car il s'agit principalement de chaînes de connexion utilisées pour accéder à des données auxquelles elles devraient normalement normalement avoir accès.

+0

+1 d'accord, ce n'est pas tellement le client qui m'inquiète, mais vous avez toujours un administrateur technique qui travaille pour un client qui sera sarcastique s'il trouve des chaînes de connexion stocké non crypté .... –

Questions connexes