Passwort im Klartext im Konfigurationsfile? Darf man das noch?

[NickFrost]

Hallo zusammen,

ich war grad erstaunt, als ich im heruntergeladenen Konfigurationsfile (XML) mein Passwort für die Nextcloud (Server für die Sicherungen) im Klartext gelesen hab. Ich finde, das ist nicht mehr zulässig, ev. sogar gesetzlich verboten.

Wie seht ihr das ?

[lewald]

Geht es um die Konfiguration von OPNsense?

Ich finde, das ist nicht mehr zulässig, ev. sogar gesetzlich verboten.

.

1. Nun das ist ja wohl jedem selbst überlassen. Ich würde die Aussage mal als "bull..." bezeichen.

2. Es muss ja nicht so sein! Siehe Screenshot.

[meyergru]

Verboten ist es nicht, in diesem Kontext ist es nicht einmal sinnvoll. Aber vielleicht hast Du das Problem auch nicht ganz richtig verstanden:

Was man heutzutage typischerweise nicht mehr tun soll, ist, Passworte im Klartext dort zu speichern, wo sie geprüft werden (also serverseitig). Das soll dazu dienen, im Fall von Datenlecks oder Einbrüchen das Passwort zu schützen - vor allem, um ein eventuell auch bei anderen Diensten mehrfach verwendetes Passwort nicht offenzulegen.

Stell' Dir vor, Dein Passwort "supergeheim" würde bei Ebay und bei Amazon für Deine E-Mail-Adresse verwendet. Dann würde bei Klartextspeicherung und Einbruch bei Ebay auch Dein Amazon-Passwort offengelegt. Ist es aber verschlüsselt, geht das (hoffentlich) nicht.

Nun gibt es noch ein kleines Problem: Es gibt einen Unterschied zwischen Einweg-Verschlüsselung (Hashing) und Zweiweg-Verschlüsselung. Wenn die Passworte Zweiweg-Verschlüsselt sind, kann der Dienst aus dem Chiffrat das Passwort wiederherstellen und dann prüfen, ob es mit dem eingegebenen Passwort übereinstimmt. In diesem Fall könnte ein Einbruch aber eben doch zu einer Offenlegung führen, wenn das Verschlüsselungsverfahren (und die verwendeten Schlüssel)  bekannt sind. Deshalb verwenden viele Dienste heute eine Einweg-Verschlüsselung (mit zufälligem Salt), womit nur geprüft wird, ob das eingegebene Passwort den selben Hashwert ergibt, der gespeichert wurde. Mit dem Hash allein ist aber eine Rückrechnung nicht möglich (deswegen: Einweg-Verschlüsselung).

Was nun die Speicherung Deines NextCloud-Passworts in OpnSense angeht, handelt es sich um die Speicherung nicht auf dem Server, sondern auf dem Client. Und dort benötigt man immer zwingend das Klartext-Passwort. Anderenfalls kann man es dem Server ja nicht zeigen. Den Hashwert kann man ebenfalls nicht vorlegen, da man nicht weiß, wie dieser auf dem Server gebildet wird, bzw. mit welchem zufälligen Wert (Salt) das Passwort kombiniert wurde.

Das bedeutet also automatisch, dass ein Hashing auf der Client-Seite nicht möglich ist. Möglich wäre eine Zweiweg-Verschlüsselung, bei der in der Konfigurationsdatei ein (umkehrbares) verschlüsseltes Passwort abgelegt würde.

Das hilft aber leider gar nichts, denn im Quelltext von OpnSense könnte man dann nachlesen, wie dieses Passwort entschlüsselt werden kann - damit wäre es bei einem Datenleck genauso offengelegt wie im Klartext.


Also: Es ist weder vorgeschrieben, das Passwort auf der Client-Seite (zweiweg) zu verschlüsseln (einweg wäre nicht einmal möglich), noch ist es technisch sinnvoll.

P.S.: Was tatsächlich einweg-verschlüsselt ist in der OpnSense-Konfigurationsdatei, sind die Benutzerpassworte. Da tritt OpnSense ja auch nicht in der Rolle als Client, sondern als Server auf.

[NickFrost]

1. Das verschlüsselte Speichern des Konfigurationsfile löst das Problem nicht, weil das Passwort nach dem Entschlüsseln wieder offen vorliegt. Wenn ich diese Konfigurationsdatei zu irgendeinem Zweck intern oder an einen Support weiterreiche, darf ein Passwort nicht offen lesbar sein.

2. Das ist natürlich kein Bullshit, sondern insbesondere für Firmen in der DS-GVO vorgeschrieben. Der sorgfältige Umgang mit Daten und insbesondere Passwörtern kann nicht mehr so sorglos gemacht werden.

3. Natürlich kann das Passwort nicht gehasht werden. Es muss zur Anmeldung an die Nextcloud ja wieder vorliegen. Aber man könnte das Passwort z.B. mit Blowfish, Twofish oder was anderem verschlüsseln. Damit lässt sich das Passwort wieder herstellen.

Das OPnsense Passwort ist ja auch verschlüsselt. Es gibt keinen Grund, dies nicht auch hier mit diesem Passwort zu machen. Ich kenn auch kein professionelles Gerät, dass Passwörter unverschlüsselt speichert (ausser chinesische).

[meyergru]

3. Natürlich kann das Passwort nicht gehasht werden. Es muss zur Anmeldung an die Nextcloud ja wieder vorliegen. Aber man könnte das Passwort z.B. mit Blowfish, Twofish oder was anderem verschlüsseln. Damit lässt sich das Passwort wieder herstellen.

Das OPnsense Passwort ist ja auch verschlüsselt. Es gibt keinen Grund, dies nicht auch hier mit diesem Passwort zu machen. Ich kenn auch kein professionelles Gerät, dass Passwörter unverschlüsselt speichert (ausser chinesische).

Eben in der Wiederherstellbarkeit liegt das Problem: Es hilft nichts. Und wie ich schon schrieb, es gibt einen eklatanten Unterschied je nach Rolle Client oder Server. Auch mit der DSGVO hast Du Unrecht:

Siehe: https://dsgvo-gesetz.de/themen/verschluesselung/

Dabei sind der Stand der Technik, die Implementierungskosten, sowie die Art, der Umfang, die Umstände und der Zweck der Verarbeitung zu berücksichtigen. Neben diesen Kriterien sind auch die unterschiedlichen Eintrittswahrscheinlichkeiten und die Schwere des Risikos für die Rechte und Freiheiten der Betroffenen mit einzubeziehen. Dementsprechend sollte der Grad der getroffenen Sicherheitsmaßnahmen angepasst werden. Die Verschlüsselung wird dabei explizit als eine solche Maßnahme im nicht abschließenden Katalog des Art. 32 Abs. 1 EU-DSGVO angeführt.

Lies:

1. Der Kontext ist relevant (Client vs. Server)
2. Verschlüsselung als Maßnahme ist nicht vorgeschrieben, sondern wird lediglich empfohlen. Und wo sie keinen Sinn macht, macht sie keinen Sinn.


P.S.: Die OpnSense-Passworte sind nicht (zweiweg)-verschlüsselt, sondern gehasht, was viel besser ist (aber eben für das NextCloud-Passwort unmöglich).

[Patrick M. Hausen]

In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...

Das CMS ist gegenüber der Datenbank ebenfalls ein Client.

[NickFrost]

Klingt nach faulen Ausreden :)

Ein Passwort ist ein Passwort. Egal wo es gebraucht wird. Es kann kostenlos so verschlüsselt werden, dass es wieder vollständig hergestellt werden kann. Damit entfallen auch alle deine angebrachten Argumente.

Ein Passwört verschlüsselt in einem Konfigurationsfile zu speichern ist einfach Stand der Technik.

[NickFrost]

In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...

Das CMS ist gegenüber der Datenbank ebenfalls ein Client.

Das ist klar, aber diese Datei gibt man ja auch nicht weiter. Das ist praktisch sowas wie die Passwortdatei.

[Patrick M. Hausen]

Wie soll es denn mitten in der Nacht, wenn der Cronjob für das Nextcloud-Backup läuft, entschlüsselt werden, ohne Benutzereingriff?

Dann musst du das Blowfish-Secret eben im Klartext irgendwo hin legen. Gewonnen ist damit dann nichts.

[meyergru]

In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...

Rischtisch. Und zwar aus genau den angeführten Gründen.

Klingt nach faulen Ausreden :)

Ein Passwort ist ein Passwort. Egal wo es gebraucht wird. Es kann kostenlos so verschlüsselt werden, dass es wieder vollständig hergestellt werden kann. Damit entfallen auch alle deine angebrachten Argumente.

Ein Passwört verschlüsselt in einem Konfigurationsfile zu speichern ist einfach Stand der Technik.

Nochmal: Das wäre zwar kosten-, aber auch zwecklos, wenn ich das Verfahren zum Entschlüsseln im Quelltext von OpnSense nachlesen kann, wie Patrick richtig schreibt.

Wirksamer Schutz böte nur ein Hashing - und das ist für Clients funktionsverhindernd.

[Patrick M. Hausen]

In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...

Das CMS ist gegenüber der Datenbank ebenfalls ein Client.

Das ist klar, aber diese Datei gibt man ja auch nicht weiter. Das ist praktisch sowas wie die Passwortdatei.

Quatsch. Das ist die Konfigurationsdatei des CMS, die natürlich mit Git versioniert, und automatisiert deployed wird. Dafür gibt es dann Techniken wie Ansible Vault, aber auf dem produktiven System landet sie wieder im Klartext. Und im nächtlichen Backup landet sie im Klartext. Etc.

[NickFrost]

Quatsch. Das ist die Konfigurationsdatei des CMS, die natürlich mit Git versioniert, und automatisiert deployed wird. Dafür gibt es dann Techniken wie Ansible Vault, aber auf dem produktiven System landet sie wieder im Klartext. Und im nächtlichen Backup landet sie im Klartext. Etc.

Keine Ahnung, was du für Software hast. Aber die config.php mit den Zugangsdaten gehe ich sicher nicht mit Git versionieren. Dafür gibt es .gitignore. Aber klar, es gibt auch normale Backups. Aber auch diese bleiben intern und werden nicht weitergegeben.

Es mir nur darum, dass man nicht unbedingt damit rechnet, dass ein Gerät eine Konfigurationsdatei erstellt mit Klartextpasswörtern. Es ist nicht unüblich, dass man solche Dateien gelegentlich mal einem Support z.B. bei Cisco oder Zyxel einschickt.

[NickFrost]

Nochmal: Das wäre zwar kosten-, aber auch zwecklos, wenn ich das Verfahren zum Entschlüsseln im Quelltext von OpnSense nachlesen kann, wie Patrick richtig schreibt.

Das Verfahren ist bei OpenSource immer bekannt. Aber nicht die Schlüssel (oder Secrets oder was auch immer) zum Verschlüsseln. Die werden individuell separat beim Anwender generiert.

[Patrick M. Hausen]

Es mir nur darum, dass man nicht unbedingt damit rechnet, dass ein Gerät eine Konfigurationsdatei erstellt mit Klartextpasswörtern. Es ist nicht unüblich, dass man solche Dateien gelegentlich mal einem Support z.B. bei Cisco oder Zyxel einschickt.

Pruuust  ;D

Die Passwort-Hashes in Cisco IOS sind reversibel, also nicht wirklich Hashes, und Algorithmus und Secret sind bekannt. Das ist nur Obfuscation.

Das Verfahren ist bei OpenSource immer bekannt. Aber nicht die Schlüssel (oder Secrets oder was auch immer) zum Verschlüsseln. Die werden individuell separat beim Anwender generiert.

Ach! Aber damit das Gerät das Passwort selbständig im Klartext bekommen kann, z.B. bei jedem Nextcloud-Backup am Beispiel der OPNsense, muss dann der Schüssel ebenfalls wieder im Klartext auf dem Gerät vorliegen, oder?

Und damit Bestandteil eines Konfigurations-Backups sein. Schließlich ist der Sinn eines Konfigurations-Backups, dass man das System nur damit vollständig wiederherstellen kann.

[NickFrost]

Die Passwort-Hashes in Cisco IOS sind reversibel, also nicht wirklich Hashes, und Algorithmus und Secret sind bekannt. Das ist nur Obfuscation.

Gut aber das kann ich ja nicht wissen :) Ich glaube ja immer noch an das Gute im Menschen ;) Aber nur weil die das ev. nicht richtig machen, ist es kein Argument es bei OPNsense nicht richtig zu machen.

Ach! Aber damit das Gerät das Passwort selbständig im Klartext bekommen kann, z.B. bei jedem Nextcloud-Backup am Beispiel der OPNsense, muss dann der Schüssel ebenfalls wieder im Klartext auf dem Gerät vorliegen, oder?
Und damit Bestandteil eines Konfigurations-Backups sein. Schließlich ist der Sinn eines Konfigurations-Backups, dass man das System nur damit vollständig wiederherstellen kann.

Richtig, der Schlüssel muss vorliegen. Aber so wie ich das kenne, eben nicht im Konfigurations-Backup.

Der könnte ja in einer 2. Datei liegen, welche man nicht weiterreicht.

Es geht mir primär nur darum, dass das Passwort nicht unverschlüsselt in der Konfigurationsdatei ist. So aus meiner Erfahrung liegen Kopien von diesen Dateien mit der Zeit an allen möglichen Orten :) Sie werden auf dem Desktop gespeichert, sie werden dem Kollegen weitergereicht, sie werden an ungeschützen Orten gespeichert oder eben an Supportleute weitergereicht etc., etc.