Was ist der beste Weg, um Verbindungszeichenfolgen in .NET-DLLs zu speichern?

Question

Die Anwendung, die mein Team derzeit entwickelt, verfügt über eine DLL, die für den gesamten Datenbankzugriff verwendet wird.Die Anwendung kann keine vertrauenswürdige Verbindung verwenden, da sich die Datenbank hinter einer Firewall befindet, der Domänenserver jedoch nicht.Es scheint also, dass die Verbindungszeichenfolge einen DB-Benutzernamen und ein Kennwort enthalten muss.In der DLL ist derzeit die Datenbankverbindungszeichenfolge fest codiert, aber ich möchte dies beim Start nicht tun, da die Assembly zerlegt werden kann und der Benutzername und das Kennwort direkt dort offen liegen würden.

Eine der Anforderungen besteht darin, dass das Passwort alle paar Monate geändert werden muss, sodass wir dies für unsere interne Benutzerbasis einführen müssen.

Gibt es eine Möglichkeit, das Passwort so verschlüsselt zu speichern, dass wir es problemlos an die gesamte Benutzerbasis verteilen können, ohne es in der Assembly zu speichern?

AKTUALISIEREN:Vielen Dank an alle, die geantwortet haben.Ich werde versuchen, mir einige der Fragen zu beantworten ...Die Daten-DLL wird sowohl von ASP.NET WebForms als auch von VB.NET WinForms verwendet.Ich verstehe, dass Anwendungen ihre eigenen Konfigurationsdateien haben können, aber ich habe nichts zu Konfigurationsdateien für DLLs gesehen.Leider kann ich den Jon Galloway-Beitrag bei der Arbeit nicht erreichen, daher kann ich nicht beurteilen, ob das funktionieren wird.Aus entwicklungstechnischer Sicht möchten wir Webdienste nicht intern nutzen, sondern sie möglicherweise irgendwann im nächsten Jahr Dritten zur Verfügung stellen.Ich glaube nicht, dass Identitätswechsel funktionieren wird, da wir den Benutzer nicht über die Firewall authentifizieren können.Da ein Benutzer (oder ehemaliger Benutzer) ein Angreifer sein kann, halten wir es vor allen geheim!

Answer 1

Ich bin nicht sicher, aber ich glaube, Sie können es in eine Konfigurationsdatei einfügen und die Konfigurationsdatei verschlüsseln.

Aktualisieren:Siehe Jon Galloways Beitrag Hier.

Answer 2

Gehen Sie einfach davon aus, dass die Bösewichte die Anmeldeinformationen aus Ihrer Konfigurationsdatei erhalten.Das bedeutet, dass sie sich bei Ihrer Datenbank anmelden und alles tun können, wozu der Benutzer in der Lage ist.Stellen Sie also sicher, dass der Benutzer nichts Schlimmes tun kann, z. B. direkt auf die Tabellen zugreifen kann.Wenn Sie diesem Benutzer nur die Möglichkeit geben, bestimmte gespeicherte Prozeduren auszuführen, sind Sie in einer besseren Verfassung.Dies ist ein Ort, an dem Sprocs glänzen.

Answer 3

Ich hasse es, das zu sagen, aber sobald Sie etwas auf einen Client-Rechner laden, geht die Sicherheit dieser Daten verloren.

Wenn Ihr Programm diese Zeichenfolge entschlüsseln möchte, müssen Sie davon ausgehen, dass ein Angreifer dasselbe tun kann.Eine Möglichkeit wäre das Anhängen eines Debuggers an Ihr Programm.

Die Verbindungszeichenfolge auf einem Server zu speichern und sie über eine Webverbindung abzurufen, hört sich gut an, bis Ihnen klar wird, dass Sie auch Sicherheit für diese Webverbindung benötigen. Andernfalls könnte sich ein Angreifer genauso gut als Ihr Programm ausgeben und mit der Webverbindung kommunizieren.

Lassen Sie mich eine Frage stellen.Vor wem verheimlichen Sie die Verbindungszeichenfolge?Der Benutzer oder ein Angreifer?Und wenn der Benutzer, warum?

Answer 4

Es gibt auch noch einige andere Ideen.Sie können jederzeit einen Identitätswechsel verwenden.Sie können auch die Unternehmensbibliothek (Common Library) verwenden.

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Answer 5

.NET unterstützt die Verschlüsselung solcher Konfigurationswerte.Sie könnten es in einer Konfigurationsdatei belassen, jedoch verschlüsselt.

Answer 6

Sie möchten die DLL mit allen Setup-Informationen an einem konfigurierbaren Ort verteilen können, aber Tatsache ist, dass Sie keine der praktischen .NET-Konfigurationsdateien für eine DLL haben können, es sei denn, Sie machen etwas Benutzerdefiniertes.

Möglicherweise müssen Sie überdenken, welche Verantwortung Ihre DLL haben sollte.Wäre es möglich oder sinnvoll zu verlangen, dass die Verbindungszeichenfolge vom Benutzer Ihrer Bibliothek übergeben wird?Ist es wirklich sinnvoll, dass Ihre DLL eine Konfigurationsdatei liest?

Answer 7

Wenn es sich bei der App um eine ASP.NET-App handelt, verschlüsseln Sie einfach den Abschnitt mit den Verbindungszeichenfolgen Ihrer App web.config.

Wenn es sich bei der App um eine Clientanwendung handelt, die auf mehreren Computern ausgeführt wird, sollten Sie anstelle der lokalen Speicherung der Verbindungszeichenfolge die Verwendung eines Webdiensts oder eines anderen sicheren Mechanismus zur zentralen Speicherung in Betracht ziehen.Dies würde zukünftige Aktualisierungen erleichtern und Sie speichern die Verbindungszeichenfolge nicht lokal.

Nur ein paar Gedanken.

Aktualisiert: @lassevk

„Die Verbindungszeichenfolge auf einem Server zu speichern und über eine Webverbindung abzurufen, hört sich gut an, bis Ihnen klar wird, dass Sie auch Sicherheit für diese Webverbindung benötigen. Andernfalls könnte sich ein Angreifer genauso gut als Ihr Programm ausgeben und mit der Webverbindung kommunizieren.“ "

Die Sicherheit des Webdienstes war implizit.Abhängig von der Art der Bereitstellung gibt es zahlreiche Optionen, zum Beispiel clientseitige Zertifikate.

Answer 8

Mehrere Möglichkeiten:

1. In web.config speichern und verschlüsseln
2. In DLL speichern und verschleiern (Dotfuscator)
3. Speichern Sie eines in web.config (natürlich verschlüsselt) und verbleiben Sie in der Datenbank (wenn Sie mehrere verwenden müssen und die Verschlüsselung/Entschlüsselung mühsam wird).