Frage:
Standards zum Verschlüsseln von Passwörtern in Konfigurationsdateien?
C. Ross
2012-05-16 20:40:17 UTC
view on stackexchange narkive permalink

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, den Zugriff mit der Anmeldung zu verknüpfen 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 mit der Tatsache um, dass der Verschlüsselungsschlüssel für das Kennwort entweder fest codiert oder in einer weiteren Konfigurationsdatei gespeichert sein muss?
  • Sollten die Verschlüsselungsschlüssel für das Kennwort menschlich sein lesbar?
Wenn Ihre Organisation über diese Richtlinie verfügt, sollten Sie möglicherweise einen der Sicherheitskontakte in Ihrer Organisation finden, um herauszufinden, welche Mechanismen für die Adressierung dieser Richtlinie als genehmigt gelten.
Fünf antworten:
D.W.
2012-05-16 21:52:36 UTC
view on stackexchange narkive permalink

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 schlechter Auswahlmöglichkeiten.

Folgende Optionen stehen zur Verfügung: Lassen Sie einen Benutzer das Kennwort beim Start eingeben (dies ist schlecht, Denn wenn Ihr Server neu gestartet wird, ist der Server jetzt nicht mehr erreichbar, 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.

Verschlüsseln des in der Konfigurationsdatei gespeicherten Kennworts hilft nicht, 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 , Wo soll ein Schlüssel für die Verschlüsselung gespeichert werden? Wie gehen Open Source-Projekte mit sicheren Artefakten um?, Wie kann ich Daten mit Java entschlüsseln, ohne den Schlüssel fest zu codieren? ?, Passwort in Datei .php, Wo speichere ich den Schlüssel sicher für ein System, auf dem die Quelle sichtbar ist?.

PS Im Prinzip könnten Sie ein TPM verwenden, um das Passwort zu speichern. In der Praxis führt dies jedoch zu aktuellen Problemen, sodass es für die meisten Leute wahrscheinlich nicht praktikabel ist.

Ich stimme Ihnen im Allgemeinen zu, aber können Sie die besonderen Probleme in der Frage ansprechen?
@C.Ross, Hmm, ich dachte, ich hätte bereits alle Probleme in der Frage angesprochen. Kurz gesagt: Das Verschlüsseln des Kennworts in der Konfigurationsdatei ist sinnlos, es sei denn, Sie haben einen besseren Ort zum Speichern des Entschlüsselungsschlüssels. In diesem Fall können Sie das Kennwort auch einfach an diesem Ort speichern und die Verschlüsselung überspringen. Meine flippige Antwort auf Ihre Fragen lautet also: Tu das nicht, das ist einfach albern. Oder eine etwas ernstere Antwort: Es könnte hilfreich sein, wenn Sie Ihr Bedrohungsmodell beschreiben und erklären, wie Sie den Entschlüsselungsschlüssel schützen und warum Sie das Kennwort nicht auf die gleiche Weise schützen können.
@D.W. Warum ist das Hardcodieren des pwd viel schlechter als das Speichern in einer Konfigurationsdatei? Zumindest wenn ein gut gestalteter "find" -Befehl fest codiert ist, findet er das Passwort nicht
TPM führt hauptsächlich zu Blutungen, ohne das Problem zu beeinträchtigen ...
@lisa17, denn wenn es geändert werden muss (und es muss geändert werden, egal wie sehr Sie es ablehnen), ist derjenige, der es ändern muss, bestenfalls FUBAR und mit allen privaten Unternehmensdaten, die auf The Pirate Bay veröffentlicht werden schlimmstenfalls.
@lisa17 Wenn Sie es naiv fest codieren, kann es jeder mit dem Unix-Befehl "strings" leicht herausziehen.
@lisa17 Neben guten Antworten von HubertKario und C. Ross finden Sie auch meine Antwort auf diese Frage aus weiteren Gründen: [Passwort in Datei .php] (http://security.stackexchange.com/q/13353/971).
Wenn Sie mit einer ASP.net-Webanwendung arbeiten. Sie sollten die Konfigurationsdatei verschlüsseln, wenn ein Kennwort darin gespeichert ist. Sie können eine Konfigurationsdatei sogar verschlüsseln, auch wenn sie nicht bereitgestellt wird. Es handelt sich um eine .NET-Anwendung, die auf der Maschinenkonfiguration selbst basiert.
bangdang
2012-05-17 04:14:33 UTC
view on stackexchange narkive permalink

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.

Bei den anderen Ansätzen zur vorbeugenden Steuerung wird wahrscheinlich die Verschlüsselung verwendet Es gibt viele verschiedene Möglichkeiten, den Schlüssel zu schützen. Ohne auf die Details einzugehen oder zu wiederholen, was DW bereits veröffentlicht hat, 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 korrelieren (z. B. Neustart des Servers / Dienstes) mit Zugriff auf die Schlüsseldatei. Jede andere Zugriffsanforderung (erfolgreich oder nicht) auf die Schlüsseldatei kann auf eine abnormale Aktivität hinweisen.

Um zu Ihrer Warteschlange zu gelangen Hier ist meine Meinung:

Wenn Sie ein 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. In ähnlicher Weise 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 Kennwort für Menschen lesbar sein? Dies hängt davon ab. 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 schwer zu bestätigen ist Sie können den Schlüssel jederzeit codieren / verschlüsseln, aber solche Methoden schrecken niemanden ab, der klug genug ist, um einen Screenshot zu erstellen. Sie können jedoch einfache "Schlüssel" (eher wie Kennwörter) als Eingabe für eine Schlüsselerweiterungsfunktion verwenden In diesen Fällen können zusätzliche Maßnahmen wie die Codierung einen zusätzlichen Wert im Verhältnis zu den Kosten der Komplexität hinzufügen.

Wenn überhaupt, besteht ein guter Ansatz darin, mehrere Ebenen von Kontrollen zu implementieren. Vorbeugende Kontrollen sind beim Detektiv schwieriger Forts Rollen sind im Allgemeinen einfacher zu implementieren. 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.

Neil McGuigan
2013-11-20 01:32:03 UTC
view on stackexchange narkive permalink

Speichern Sie das Kennwort in einer (nicht sitzungsbezogenen) O / S-Benutzerumgebungsvariablen und führen Sie das Programm als dieser Benutzer aus.

Vorteile:

  1. Sie werden das Kennwort 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?), Ihre Passwörter werden 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. Wenn Sie die Datei verschlüsseln, wie sichern Sie Ihren Schlüssel?

  5. Löschen Sie Ihre Envvars, bevor Sie neue Prozesse starten übergeben

  6. ol>

    Ein Vorteil eines HSM besteht darin, dass Benutzer oder Root den HSM zwar zum Entschlüsseln eines Werts verwenden können, jedoch niemals den Schlüssel erhalten können darin.

Wie legen Sie die Umgebungsvariable anders als in einer anderen Datei (z. B. ~ / .bashrc) fest?
@AndreasMaier würden Sie sie dauerhaft in einer Datei speichern, ja, aber * nicht * über die Quellcodeverwaltung.Sie möchten ein Konfigurationsverwaltungssystem wie Ansible verwenden.
Sergey Malych
2014-02-08 21:41:35 UTC
view on stackexchange narkive permalink

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

  1. Speichern von Kennwörtern auf dem lokalen Computer in einem neuen Datei (die auch besser verschlüsselt werden kann) und beschränken Sie den Zugriff auf die Datei
  2. , um Kennwörter auf einem anderen Server zu speichern, 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 Zugriff mit dem Zertifikat
  4. , das einige Organisationen speichern seine Passwörter als Registrierungsschlüssel oder mit DPAPI - http://msdn.microsoft.com/en-us/library/ms995355.aspx
  5. unter Verwendung von OTP unter Verwendung des Kontoverwaltungsdienstes Verwenden Sie den Proxyserver, um auf vertrauliche Daten zuzugreifen und den Zugriff auf den Proxy zu beschränken.
  6. ol>

    .

    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 mit der Tatsache um, dass die Verschlüsselung Der Schlüssel für das Passwort muss entweder fest codiert oder in einer weiteren Konfigurationsdatei gespeichert sein.

    unter Verwendung von Zugriffsbeschränkungen und Überwachung der Datei

    Soll der Verschlüsselungsschlüssel verwendet werden für Passwort menschlich lesbar sein? Wenn Sie sichere und von Menschen lesbare Passwörter meinen, gibt es überhaupt kein Problem

Alle diese Optionen scheinen das gleiche "Bootstrapping" -Problem zu haben. Angenommen, das Kennwort für Ihre Anwendung befindet sich auf einem anderen Server, und Sie verwenden einen Authentifizierungsdienst, um dieses Kennwort abzurufen. Wie authentifizieren Sie sich bei diesem Dienst (natürlich muss der Zugriff auf den Dienst, der Ihnen Ihr Kennwort gibt, authentifiziert werden ...)?
Für die Authentifizierung sind möglicherweise einige Identitätsausdrücke für die Autorisierung erforderlich. Wenn Sie eine Firewall und ein NAC verwenden, sollte dieses Problem meistens gelöst werden, wenn Sie eine bestimmte Barriere zwischen Servern definieren. Bei Zertifikaten ist es schwierig, den privaten Schlüssel vom Computer zu erhalten Wenn der Benutzer, der den Prozess ausführt, ein schwer zu erratendes Kennwort hat, ist es größtenteils gesichert. Um noch sicherer zu sein, kann die Verwendung von HSM die Lösung zum Speichern aller Schlüssel sein
Es hängt wirklich von der Art der Anwendung ab, über die wir sprechen. Ich würde vorschlagen, dass die meisten Anwendungen, für die ein Kennwort in einer Konfigurationsdatei erforderlich ist (im Gegensatz zu den vom Benutzer eingegebenen), Dienste sind, die unbeaufsichtigt auf einem Server ausgeführt werden sollen. In diesem Fall sind Fingerabdrücke oder andere benutzerbasierte Methoden nicht besonders nützlich (da keine Benutzer sie bereitstellen können). Einige Formen des betriebssystembasierten Schutzes (wie Sie vorschlagen) können jedoch ein wenig helfen.
Nicolas C
2017-02-21 20:19:58 UTC
view on stackexchange narkive permalink

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 scheint ein Widerspruch zu sein.

Bestenfalls können Sie das Kennwort in der Konfiguration verschleiern ( Base64 , Schlüssel irgendwo auf dem Computer usw.)



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...