it-swarm-eu.dev

Standards zum Verschlüsseln von Passwörtern in Konfigurationsdateien?

Mein Arbeitsplatz hat den Standard, dass Klartextkennwörter in Anwendungskonfigurationsdateien nicht zulässig sind. Dies ist auf den ersten Blick sinnvoll genug, falls jemand Zugriff auf die Konfigurationsdateien erhält, hat er nicht automatisch Zugriff auf alle Berechtigungen dieser Anwendung. In einigen Fällen ist es möglich und offensichtlich vorzuziehen, mit der Anmeldung verknüpften Zugriff zu haben oder auf andere Weise ein Kennwort zu vermeiden, z. B. in der Windows Security für SQL Server-Authentifizierung, oder es an einem Speicherort eines Drittanbieters zu konfigurieren, z. B. in der JDBC-Konfiguration in einer J2EE-Umgebung , aber das ist nicht immer möglich.

  • Wenn ich ein Passwort in einer Konfigurationsdatei haben muss, welche Verschlüsselungsstufe sollte es tragen?
  • Wie gehen Sie damit um, dass der Verschlüsselungsschlüssel für das Passwort entweder fest codiert oder in einer weiteren Konfigurationsdatei gespeichert sein muss?
  • Sollten die Verschlüsselungsschlüssel für das Passwort für Menschen lesbar sein?
57
C. Ross

Das Folgende war also etwas zu lang für einen Kommentar ...

Vielleicht hilft es, einen Schritt zurückzutreten und die Vorteile von Präventions- und Detektivkontrollen zu vergleichen. Zu den vorbeugenden Kontrollen gehört die Verschlüsselung. Sie können das Kennwort jedoch auch verschlüsseln, um es weniger offensichtlich zu machen. Dieser Ansatz soll das Kennwort vor versehentlichem Teilen schützen (eine b32-Codierung würde weniger aussagekräftige Zeichen erzeugen (b32 erzeugt eine längere Zeichenfolge als b64). Ein solcher Ansatz erhöht nur die Schwierigkeit, sich die zufällige Folge von Zahlen zu merken, sowie die Methode, die dies tun sollte Die Base32/64-Codierung ist eine einfache Methode zum Schutz von Kennwörtern, für die keine zusätzliche Logik erstellt/verwaltet werden muss.

Die anderen Ansätze zur vorbeugenden Kontrolle würden wahrscheinlich Verschlüsselung verwenden. Es gibt viele verschiedene Möglichkeiten, den Schlüssel zu schützen. Ohne auf die Details einzugehen oder zu wiederholen, was D.W. Bereits veröffentlicht, können Sie Detektivkontrollen überlagern, um die Sicherheitslage zu verbessern. Sie können beispielsweise den Zugriff auf eine Datei überwachen, die den Schlüssel enthält. Sie können Ereignisse (z. B. Neustart des Servers/Dienstes) mit dem Zugriff auf die Schlüsseldatei korrelieren. Jede andere (erfolgreiche oder nicht erfolgreiche) Zugriffsanforderung auf die Schlüsseldatei kann auf eine abnormale Aktivität hinweisen.

Um zu Ihren Fragen zu gelangen, hier meine Meinung:

wenn Sie das Passwort in einer Konfigurationsdatei speichern müssen, würde ich empfehlen, das Passwort nach Möglichkeit zumindest zu verschlüsseln. Das Codieren des Kennworts verringert die Wahrscheinlichkeit, dass es durchgesickert ist, falls jemand durch die Datei blättert, z. B. wenn ein Mitarbeiter des Anbieters den Support überwacht. Das Verschlüsseln des Passworts ist viel sicherer, erfordert jedoch zusätzliche Komplexität.

Umgang mit der Tatsache, dass ein Schlüssel fest codiert oder in einer anderen Datei gespeichert werden muss. Das Trennen des Verschlüsselungsschlüssels in einer anderen Datei erhöht die Schwierigkeit für jemanden, den Schlüssel anzuzeigen. Sie können beispielsweise die Zugriffssteuerung verwenden, um den Zugriff auf die Schlüsseldatei zu beschränken, aber dennoch eine offenere ACL für die Konfigurationsdatei beizubehalten. Ebenso können Sie die Überwachung für den Zugriff auf die Schlüsseldatei implementieren, mit der Sie auf Ereignisse zurückgreifen können, für die die Verwendung eines Schlüssels erforderlich ist. Eine harte Codierung des Schlüssels kann in Ordnung sein, wenn Sie den Zugriff auf die Binärdatei beschränken. Eine sorgfältige Codierung des Passworts kann leicht erkannt werden, indem "Zeichenfolgen" für die Binärdatei ausgeführt werden. Sie können das fest codierte Kennwort verschlüsseln/verschlüsseln (dh eine separate Funktion (möglicherweise mit Überwachung) benötigen, um das Kennwort zu dekodieren. Dies erhöht jedoch die Komplexität für Entwickler und Administrator (dh wie ändert man den Schlüssel, ohne die Binärdatei neu zu erstellen/neu zu kompilieren) ?).

Sollten die Verschlüsselungsschlüssel für das Passwort für Menschen lesbar sein? Es hängt davon ab, ob. Es gibt nur eine begrenzte Anzahl von Möglichkeiten, den Schlüssel zu schützen. Ein Verschlüsselungsschlüssel wird normalerweise als alphanumerische Zeichenfolge angesehen, die nur schwer im Speicher gespeichert werden kann. Sie können den Schlüssel jederzeit verschlüsseln, aber solche Methoden schrecken niemanden ab, der klug genug ist, um einen Screenshot zu machen. Sie können jedoch einfache "Schlüssel" (eher wie Kennwörter) als Eingabe für eine Schlüsselerweiterungsfunktion verwenden. In diesen Fällen erhöhen möglicherweise zusätzliche Maßnahmen wie die Codierung einen zusätzlichen Wert im Verhältnis zu den Kosten der Komplexität.

Wenn überhaupt, besteht ein guter Ansatz darin, mehrere Ebenen von Steuerelementen zu implementieren. Vorbeugende Kontrollen sind schwieriger, während Detektivkontrollen im Allgemeinen einfacher zu implementieren sind. Das Trennen von Schlüsseldateien könnte die Gesamtarchitektur und die Implementierung von Steuerelementen vereinfachen. Unabhängig davon, ob vorbeugende oder detektivische Kontrollen verwendet werden, ist die Aktivierung einiger Überwachungsfunktionen zusammen mit der Überprüfung der Überwachungsprotokolle ein Muss. Auf diese Weise können Sie im Falle eines Unwahrscheinlichen (Zugriff auf den Schlüssel) Korrekturmaßnahmen ergreifen.

25
bangdang

Wenn Sie einen Server ausführen, der ein Kennwort für den Zugriff auf einen Remotedienst benötigt, gibt es keine gute Lösung. Das Speichern des Kennworts in einer Konfigurationsdatei, die an einem geeigneten Speicherort gespeichert ist, ist wahrscheinlich das Beste aus einer Reihe von schlechten Entscheidungen.

Folgende Optionen stehen zur Auswahl: Lassen Sie einen Benutzer beim Start das Kennwort eingeben (dies ist schlecht, da der Server beim Neustart Ihres Servers nicht erreichbar ist, bis eine Person physisch zum Server gehen und das Kennwort eingeben kann). Codieren Sie das Passwort fest in den Quellcode des Servercodes (dies ist viel schlimmer als das Einfügen in eine Konfigurationsdatei). oder speichern Sie das Passwort in einer Konfigurationsdatei (die am wenigsten schlechte aller Optionen). Bei der Konfigurationsdatei müssen Sie vor allem darauf achten, dass sie außerhalb Ihres Webstamms gespeichert ist und die Dateiberechtigungen ordnungsgemäß gesperrt sind.

Das Verschlüsseln des in der Konfigurationsdatei gespeicherten Passworts hilft nicht weiter, denn wo speichern Sie jetzt den Entschlüsselungsschlüssel? Sie haben das Problem gerade verschoben. "Es sind Schildkröten ganz unten" ist keine akzeptable Antwort.

Unter Windows können Sie auch das Kennwort in DPAPI speichern. Dies hilft ein wenig für Desktop-Anwendungen, ist jedoch für unbeaufsichtigte Server nicht sehr nützlich.

Weitere Informationen finden Sie auf dieser Website: Speichern Sie ein Kennwort, um Benutzerinteraktionen zu vermeiden. , Speicherort eines Schlüssels für die Verschlüsselung , Wie werden Open Source-Projekte ausgeführt? Sichere Artefakte behandeln? , Wie kann ich Daten mit Java entschlüsseln, ohne den Schlüssel fest zu codieren? , Passwort in Datei .php , Wo tun Ich speichere den Schlüssel sicher für ein System, in dem die Quelle sichtbar ist? .

P.S. Im Prinzip könnten Sie ein TPM verwenden, um das Passwort zu speichern. In der Praxis führt dies jedoch zu Problemen mit dem neuesten Stand der Technik, sodass es für die meisten Leute wahrscheinlich nicht praktikabel ist.

37
D.W.

Speichern Sie das Kennwort in einer O/S-Benutzerumgebungsvariablen (außerhalb der Sitzung) und führen Sie das Programm als dieser Benutzer aus.

Vorteile:

  1. Sie werden das Passwort niemals versehentlich in die Quellcodeverwaltung einchecken, da keine Datei zum Einchecken vorhanden ist.

  2. Wenn Sie die Dateiberechtigungen für Ihre Konfigurationsdatei vermasseln (was passiert nie richtig?), Werden Ihre Kennwörter nicht gefährdet

  3. Kann nur vom Benutzer oder Root gelesen werden (wie eine Konfigurationsdatei, wie ein privater Schlüssel zum Schutz einer verschlüsselten Datei)

  4. Wie sichern Sie Ihren Schlüssel, wenn Sie die Datei verschlüsseln?

  5. Löschen Sie Ihre Envvars, bevor Sie neue Prozesse starten, da diese möglicherweise durchlaufen werden

Ein Vorteil eines HSM besteht darin, dass Benutzer oder Root-Benutzer zwar verwenden können, um einen Wert zu entschlüsseln, jedoch niemals den darin enthaltenen Schlüssel erhalten können.

5
Neil McGuigan

Die lokale Kennwortspeicherung ist ein langes Problem, mit dem ich mich befasst habe. Da die Verschlüsselung nicht kugelsicher ist, aber möglicherweise hilft, gibt es nur wenige andere Optionen:

  1. speichern Sie Kennwörter auf dem lokalen Computer in einer neuen Datei (die auch besser verschlüsselt werden kann) und beschränken Sie den Zugriff auf die Datei
  2. speichern Sie Passwörter auf einem anderen Server, der sich über OAUTH oder einen anderen Authentifizierungsdienst) authentifiziert. Schauen Sie sich tahoe-lafs an: https://tahoe-lafs.org/trac/tahoe- lafs
  3. verwenden eines verschlüsselten lokalen Dienstes, der Kennwörter speichert, und Verwenden eines Zertifikats
  4. einige Organisationen speichern ihre Kennwörter als Registrierungsschlüssel oder mit DPAPI - http://msdn.Microsoft.com/en-us/library/ms995355.aspx
  5. verwenden von OTP mithilfe des Kontoverwaltungsdienstes
  6. verwenden des Proxyservers, um auf vertrauliche Daten zuzugreifen und den Zugriff auf den Proxy einzuschränken

.

und für Ihre Fragen:

Wenn ich ein Passwort in einer Konfigurationsdatei haben muss, welche Verschlüsselungsstufe sollte es tragen?

sie müssen nie Passwörter in Ihrem Code haben, aber es ist der einfachste und unsicherste Weg.

Wie gehen Sie damit um, dass der Verschlüsselungsschlüssel für das Passwort entweder fest codiert oder in einer weiteren Konfigurationsdatei gespeichert sein muss?

verwenden von Zugriffsbeschränkungen und Überwachen der Datei

Sollten die Verschlüsselungsschlüssel für das Passwort für Menschen lesbar sein? Wenn Sie sichere und von Menschen lesbare Passwörter meinen, gibt es überhaupt kein Problem

4
Sergey Malych

Meine 2 Cent hier sind, dass Sie aus Gründen der perfekten Sicherheit möchten, dass die Anwendung etwas tun kann (ein Kennwort lesen), was ein Angreifer auf dem physischen Computer mit denselben Berechtigungen nicht tun sollte, was ein Widerspruch zu sein scheint .

Bestenfalls könnten Sie verschleiern das Passwort in der Konfiguration ( Base64 , irgendwo auf dem Computer eingeben, etc ...)

0
Nicolas C