Existe-t-il d'autres alternatives sécurisées à la classe .Net SQLConnection?

Question

Je suis très surpris de cette question n'a pas été discutée en profondeur:

This article nous dit comment utiliser windbg pour vider une chaînes de processus .Net en cours d'exécution dans la mémoire.

J'ai passé beaucoup de temps à faire des recherches sur la classe SecureString, qui utilise des blocs de mémoire bloqués non gérés, et conserve également les données cryptées. Des trucs géniaux.

Le problème survient lorsque vous utilisez sa valeur et l'attribuez à la propriété SQLConnection.ConnectionString, qui est du type System.String. Qu'est-ce que ça veut dire? Eh bien ...

• Il est stocké dans le texte brut
• Garbage Collection se déplace autour, laissant des copies en mémoire
• Il peut être lu avec dumps mémoire windbg

Que totalement annule la fonctionnalité SecureString! En plus de cela, la classe SQLConnection est non-héritable, je ne peux même pas lancer la mienne avec une propriété SecureString; Yay pour fermé-source. Yay. Une nouvelle couche DAL est en cours, mais pour une nouvelle version majeure et pour de nombreux utilisateurs, il faudra au moins 2 ans avant que chaque utilisateur soit mis à jour, d'autres peuvent rester indéfiniment sur l'ancienne version, pour une raison quelconque. En raison de la fréquence à laquelle la connexion est utilisée, le rassemblement à partir d'un SecureString n'aidera pas, puisque les anciennes copies immuables restent en mémoire jusqu'à ce que le GC arrive. La sécurité intégrée de Windows n'est pas une option, puisque certains clients ne travaillent pas sur des domaines, et d'autres errent et se connectent sur le net.

Comment puis-je sécuriser la chaîne de connexion, en mémoire, afin qu'elle ne puisse pas être visualisée avec windbg?

Answer 1

Si vous contrôlez une machine dans la mesure où vous pouvez lire la mémoire d'un autre processus, vous pouvez également remplacer la référence à la classe SecureString par une référence à string. Vous aurez accès à toutes les clés privées que l'autre processus peut utiliser.

Il n'y a aucune défense contre un hacker qui possède votre mémoire de processus. :)

Answer 2

Pas une vraie réponse à la question, mais encore:

Essayez d'utiliser l'authentification Windows à la place de l'authentification SQL. Même si vous parvenez à sécuriser le mot de passe dans la mémoire du programme, l'utilisateur peut le voir en utilisant le sniffer de trafic.

Un autre avantage de l'authentification Windows est que le serveur SQL n'a pas besoin de stocker les hachages de mots de passe des utilisateurs. Avec l'authentification sql, le hacker déterminé peut forcer le mot de passe de hachage ou le remplacer par un autre. En fait, le mot de passe peut être remplacé très facilement avec l'utilisation de certains programmes.

Answer 3

La communication entre un processus et un serveur Sql se passe idéalement sur un backbone et si cela est compromis, c'est le moindre de vos soucis.

Answer 4

Puisqu'il est une application de bureau côté client, si vous vous demandez que vos informations d'identification de la chaîne de connexion peuvent être exposés à certains pirates, c'est un défaut de conception ...

Si vous vous connectez à votre serveur sql avec les informations d'identification de l'administrateur, c'est votre problème. Vous devez créer un utilisateur avec des restrictions et l'utiliser dans votre application.

Si vous avez peur d'exposer votre base de données, vous pouvez accéder à un service Web depuis l'application. Ce webservice accède alors à la base de données et renvoie les résultats.