J'écris une application .NET 4.0 qui nécessite l'access à une database SQL Server (v10.50.1600) sur l'intranet. La database ne prend pas en charge les connections de security / SSPI embeddedes, seules les connections user / mot de passe. Le meilleur que j'ai réussi jusqu'ici est:
SqlConnectionSsortingngBuilder builder = new SqlConnectionSsortingngBuilder() { DataSource = Settings.SQLHostName, Encrypt = true, TrustServerCertificate = true, UserID = Settings.SQLUser, Password = "xxx", InitialCatalog = "xxx" };
Toutefois, cela nécessite que je stocke et manipule un mot de passe en text brut localement, quelque chose que je veux éviter.
Existe-t-il un moyen de donner à ADO, LINQ ou Entity Framework, etc. un mot de passe à la place d'un mot de passe pour se connecter à un server SQL?
Alors que le stockage crypté pour les strings de connection est préférable à rien, il doit éventuellement être déchiffré avant utilisation. Puisque la raison de ne pas avoir une propriété de contenu pouvant être liée sur les boîtes de mot de passe WPF est apparemment que garder les passwords en memory est une mauvaise idée, tout type de déencryption de string de connection avant l'utilisation semble mal conseillé.
L'alternative idéale serait de comprendre comment le server SQL stocke et transmet ses digests de mot de passe; appliquer le même algorithm de digestion localement; puis en envoyant le résumé au lieu du mot de passe en clair. Malheureusement, il semble que le encoding de mot de passe TDS7 décrit en partie ici:
http://dbaspot.com/ms-sqlserver/210567-tds7-8-login-packets.html
semble ne pas utiliser d'algorithm de digestion du tout. Donc, je suis probablement coincé avec la réponse de podiluska ci-dessous.
Vous pouvez crypter une string de connection dans app.config.
http://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx
http://msdn.microsoft.com/en-us/library/53tyfkaw(v=vs.100).aspx
Cependant, étant donné qu'il s'agit d'une application intranet, je reorderais de découvrir pourquoi Integrated Security n'est pas activé.
Non, il n'y en a pas. Un hachage de mot de passe est utile lorsque vous devez valider un mot de passe entrant. Cela ne sert à rien lorsque vous devez stocker un mot de passe pour vous authentifier auprès d'une ressource externe.
Si votre application est exécutée sur un server sécurisé (par exemple, une application ASP.NET), vous pouvez chiffrer les informations d'identification de la database, par exemple à l'aide de la configuration protégée .
Mais dans une application client, cela ne sera pas d'une grande aide, sauf pour dissuader les browsers occasionnels, car si votre application peut décrypter le file de configuration, un user déterminé sera également capable de le faire.