en utilisant la chaîne sécurisée pour une connexion SQL

Question

Je souhaite utiliser une chaîne SecureString pour contenir une chaîne de connexion pour une base de données. Mais dès que je mets la propriété ConnectionString de l'objet SqlConnection à la valeur de la chaîne de sécurisation, elle deviendra sûrement visible à toute autre application capable de lire la mémoire de mon application?

J'ai fait les hypothèses suivantes:
a) Je ne suis pas en mesure d'instancier un objet SqlConnection en dehors de la mémoire gérée
b) une chaîne dans la mémoire gérée peut être lu par une application telle que Hawkeye

Answer 1

Votre tout à fait juste le SecureString ne vous fournit aucun avantage quand vous devez passer la chaîne à une API managée, telle que la définition d'un ConnectionString.

Il est vraiment conçu pour une communication sécurisée avec des API sécurisées non gérées.

Microsoft pourrait théoriquement envisager de renforcer objet SqlConnection pour soutenir un ConnectionString sûr, mais je pense qu'ils sont peu susceptibles de le faire parce que:

• SecureString est vraiment utile dans une application client, où par exemple un mot de passe est construit caractère par caractère à partir de l'entrée de l'utilisateur, sans jamais avoir le mot de passe entier dans une chaîne gérée.

• Dans un tel environnement, il est plus courant d'utiliser l'authentification Windows pour les connexions à SQL Server.

• Sur un serveur, il existe d'autres moyens de protéger les informations d'identification SQL Server, en commençant par limiter l'accès au serveur aux administrateurs autorisés.

Answer 2

Si vous êtes préoccupé par la sécurité, je vous suggère d'activer SSL dans le serveur SQL et de communiquer avec lui en utilisant SSL.

Answer 3

Pourquoi la chaîne de connexion est-elle un problème? Le mot de passe ne serait-il pas ce que vous voulez protéger (sauf si vous mettez le mot de passe dans la chaîne de connexion qui est facultative pour tous les pilotes que j'ai vus). Cela étant dit, le mot de passe devra généralement être "en clair" dans la mémoire à un moment donné (sauf si le pilote a une API qui permet des mots de passe cryptés ou quelque chose, mais cela n'aiderait probablement pas beaucoup de toute façon). Généralement, ce n'est pas un problème car le processus se déroule dans un environnement sécurisé, comme sur un serveur Web ou en tant que compte administrateur système (les utilisateurs normaux ne peuvent donc pas accéder à la mémoire de processus). Si c'est sur la machine d'un client fonctionnant en userland vous devez supposer que le processus est compromis de toute façon et cela n'aiderait pas. Une fois que vous avez sécurisé le processus, vous n'avez pas à vous inquiéter de choses comme ça.

Answer 4

Attribution d'une valeur SecureString à SQLConnection.ConnectionString va contourner la sécurité, ce qui rend inutile.

Un SecureString vise à résoudre ces problèmes de chaîne normale, ref:

• pas épinglé, garbage collector peut le déplacer, laissant des copies en mémoire
• pas crypté
• Si votre processus se permuté sur le disque, la chaîne sera assis dans votre fichier d'échange
• pas mutable, en modifiant il gardera l'ancienne version et la nouvelle version à la fois dans la mémoire
• n o façon de l'effacer lorsque vous avez terminé de l'utiliser

à mon humble avis le type SecureString est un patch pour une mise en œuvre de la sécurité de mauvaise qualité, et securestring actuellement n'a pas été mis en œuvre partout dans le cadre, de sorte que ses avantages peuvent » t être utilisé complètement.

J'ai le même problème, j'opte pour le cryptage RSA stockant des informations sensibles dans la mémoire. Une autre solution consiste à héberger votre couche d'accès aux données via un service sur le serveur de base de données, et le service s'exécute sous le compte système local qui se connecte à la base de données et sert les données, tandis que l'utilisateur local n'a pas accès au service config.

Answer 5

Oui, vous pouvez et oui vous devriez utiliser SecureString pour éviter que le mot de passe ne reste en mémoire et ne s'ouvre en attaque. Plutôt que d'utiliser une chaîne de connexion sql, vous devez utiliser la nouvelle classe SqlCredential dont la propriété Password est un SecureString. S'il vous plaît se référer aux articles ci-dessous pour obtenir de l'aide.

https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcredential.password(v=vs.110).aspx

http://www.codeproject.com/Tips/408901/Storing-your-connection-string-password-in-SecureS