settings.json von IPS + sicheres/verschlüsseltes Speichern von Passwörtern

Hello :slight_smile:

Ich habe gerade, nach einem Jahr mit IPS, mit erschrecken festgestellt, dass ich gar nicht so schlau bin wie ich dachte zu sein :eek: Moment, noch nichts doofes denken, erst weiterlesen bitte :smiley: :stuck_out_tongue:

…und zwar dachte ich immer, dass ich schlau wäre, wenn ich meine Passwörter nicht im Klartext in die Skripte schreibe, sondern in einer Variable speichere. Hab mir irgendwie gedacht, das wäre besser/sicherer…

ABER eben schau ich mir zum 1. Mal die „settings.json“ an…und was sehe ich da? ALLE meine Variablen inkl. Inhalt (Passwörter) im Klartext :eek: Und man liest ja immer wieder mal von IPS „schick uns die settings.json und wir schauen mal“ … joa, dann hat IPS mal eben alle meine Passwörter :frowning:

Finde ich so irgendwie unglücklich und doof. Passwörter im Klartext auf der Platte…muss bei manchen „Diensten“ nicht wirklich sein!! Keine Ahnung was ich da für Illusionen hatte, aber irgendwie hatte ich da was anderes erhofft :confused:

So…und jetzt? Wie kann man das besser machen? Könnte IPS die Daten nicht irgendwie crypted in einer Datei/Datenbank sichern?

Oder alternativ alles selbst in den Skripten verschlüsseln mit MD5 hustlach* und salzen?! Oder mit mcrypt? Oder wie macht ihr das mit euren Passwörtern die ihr in IPS benötigt?

Danke im Voraus für eure Ideen/Kommentare!
-Chris-

In diesem Punkt gibt es keine „beste“ Lösung. Wir können keinen Hash des Kennwortes abspeichern, da wir ja das Kennwort im Klartext wiederum an die jeweiligen Dienste senden müssen. Einfach verschlüsseln würde keinen Mehrwert bringen, da wir ja den Key als Symcon GmbH kennen würden.

Die einzige Lösung, welche hier helfen würde, wäre, dass wir die Kennwort mit einem zufällig generierten Key verschlüsseln und diesen Key an einer anderen Stelle speichern als die settings.json. Das würde aber in den meisten Fällen bedeuten, dass ihr nicht mehr IP-Symcon von Rechner A nach Rechner B kopieren könnt, ohne alle Kennwörter neu einzugeben.

paresy

Man kann es einfach mit einem public Key (z.B. openssl rsa wie der ohnehin vorhandene ssh key ) verschlüssen. Der private Key zum Entschlüsseln bleibt auf dem System und kann beim Umzug kopiert werden

Tommi

Das klingt gut :slight_smile: Machst du das schon so, oder war das eine Idee wie IPS es machen könnte?

Bei der Installation würde IPS also einen Key generieren, mit diesem etwas verschlüsseln und beim Umzug auf ein anderes System kann man den Schlüssel mit kopieren um Inhalte zu verschlüsseln.

Ich denke mal laut…
> Dazu könnte man evlt. ein neues IPS-Modul verwenden, in welchem man Passwörter verschlüsselt hinterlegen kann!?
> Oder irgendwie einen eigenen Bereich im IPS, wo man seine Benutzer/Passwörter eintragen kann und dann mit Funktionen wie z.B. „IPS_PW_Get(„Fritzbox“);“ Benutzer/Passwort der Fritzbox abrufen aus dem verschlüsselten Bereich und hat das dann in einem Array/String?!
> Oder allgemein eine Funktion, wenn man diese verwendet, dass die Daten darin dann crypted gespeichert werden und nur über diese Funktion die Daten dann auch wieder „brauchbar“ abgerufen werden können?

Aber irgendwie vlt, nicht nur eine Datei zum Entschlüsseln nehmen, weil die könnte man ja mit klauen. Noch irgend eine Art Schutz dazu…aber da fällt mir spontan leider auch nichts ein. Vielleicht noch ein persönliches Passwort, dass in Kombination mit dem Key und der Funktion dann alles verschlüsselt/entschlüsselt. Und das Passwort muss man irgendwo noch eingeben beim Dienst-Start oder keine Ahnung…

Weitere/bessere Ideen sind gerne Willkommen :slight_smile: Aber ich finde da muss etwas passieren! Überall wird verschlüsselt und gemacht und getan, aber dann werden Passwörter im Klartext auf der Platte abgespeichert… Man braucht sich nur mal was einfangen und ruck zuck hat ein Bösewicht eine Datei mit ALLEN Passwörter von Apple, Router, Email, NAS, CCU, Computer, und und und :eek:

Grüße,
Chris

Für IPS setze ich es nicht ein, aber ich habe so einen „Passwordservice“ mal für einen AG gebaut. Das Prinzip war nichts besonderes: eine kleines Textfile mit allen Passwörtern, welches mit einem public Key verschlüsselt wird, damit nur der Besitzer des Private Keys es auslesen kann. Das ganze dann noch mit ein paar API Funktionen lesen und schreiben von verschiedenen Anwendungen (bash, Java,PHP,Perl) garniert und fertig ist.

Tommi

Eine asymmetrische Verschlüsselung ergibt überhaupt keinen Sinn, da der Dienst das Passwort ja benötigt. Somit muss der Key zum Entschlüsseln dem Dienst zur Verfügung stehen. Daher ist auch kein Hashing möglich. Eine asymmetrische Verschlüsselung ist nur notwendig wenn es 2 Parteien gibt. Somit bleibt wenn überhaupt nur eine symmetrische Verschlüsselung. Das heißt man legt auf der gleichen Maschine einen Key ab (in einer extra Datei) oder aber man muss es beim Start eingeben. Das letzte kommt denke ich für fast alle nicht in Frage.

Ich halte aber ehrlich gesagt das Ganze für übertrieben. Mit dem Auslagern von paar Passwörter ist es ja nicht getan. Es gibt ja auch einige PHP Variablen die schützenwerte Daten enthalten kann. Also müsste man eine komplette Passwortverwaltung in Symcon integrieren.

Sinn macht das das schon, wenn man ein zentrales Repository im Netz mit vielen Credentials für die unterschiedlichsten User hat und das über ungesicherte Medien (http, shared Filesystem) bereitstellen muss. Das ist die 2. Partei. Damit stellt man sicher, das zwar alle User/Programme/Maschinen den gleichen Store benutzen können, die Antwort auf eine gültige Anfrage aber nur für den Empfänger lesbar ist. Das Passwort zum Entschlüsseln ist dann z.B. der ssh key, welcher per Definition nur dem Empfänger bekannt sein darf/sollte. Die Anwendung/IPS//Shellscript, whatever macht dann nur noch ein get_password($anwendung, $user).

Tommi

Sinn macht das das schon, wenn man ein zentrales Repository im Netz mit vielen Credentials für die unterschiedlichsten User hat und das über ungesicherte Medien (http, shared Filesystem) bereitstellen muss.

Also die settings.json ist eine systembezogene Konfigurationsdatei. Sowas hat nichts in einem öffentlichen Repository zu suchen. Wenn man Konfigurationen teilen möchte, macht man dies definitiv anders. Und ab Version 4 kann man das sogar noch komfortabel mit Modulen machen. Ich fange auch nicht an Windowsregistry zu verschlüsseln… Aber gut ich bin dann hier mal raus.

Kein Streit bitte :slight_smile: Ich sagte nur, dass ICH das SO nicht will/möchte und suche deshalb nach Lösungen. Wie immer gibt es welche die es gut finden und andere die es schlecht finden :slight_smile:

Aber wenn so dagegen „gewettert“ wird, dann sehe ich da keine Hoffnung, weil wenn nicht genug Leute etwas wollen, dann wird es von IPS meist nicht umgesetzt…

Also nochmal die Frage FÜR MICH > wie könnte ICH (und evtl. andere die es möchten) das besser/crypted umsetzen? Wie kann ich im PHP z.B. mit einem SSL-Key etwas in IPS-Variablen verschlüsseln? Diesen SSL-Key könnte ich in eine crypted Partition legen und damit wäre die quasi auch „safe“ oder ich lasse mir da noch etwas anderes einfallen oder jemand hat noch eine andere gute Idee!? :slight_smile:

Danke im Voraus und Grüße,
Chris

PS: Nur weil andere Anbieter oder die Masse etwas nicht haben, bedeutet es nicht, dass es schlecht ist und man es nicht trotzdem in seine Software einbauen kann. Verschlüsselung wird den Leuten immer wichtiger (selbst Leuten mit weniger Ahnung denen sonst alles egal war), also warum nicht als Feature von IPS eine gute Verschlüsselungsmöglichkeit für seine Passwörter und sonstige Daten in Variablen/Skripten anbieten? Wäre sicher für den ein oder anderen ein weiter + Punkt bei der Kaufentscheidung… Wie man es in IPS dann genau umsetzt/umsetzen könnte ist dann nochmal eine andere Sache…

Ich würde gerne noch einmal erklären, dass es hier um keinen echten Sicherheitsgewinn geht. IP-Symcon muss die Kennwörter wissen. Somit ist an irgendeinem Punkt das Kennwort auch im Klartext im System. Somit ist jede Verschlüsselung, die angewendet wird, nur ein (minimales) Hindernis für denjenigen, der eure Kennwörter klauen wollen würden.

Den einzigen Vorteil einer Verschlüsselung mit getrennt gespeichertem Schlüssel sehe ich darin, dass beim Versand von der settings.json diese niemals direkt enthalten wären. Bei einem Backup unterstelle ich den meisten Usern, dass diese den Schlüssel direkt mitspeichern wollen würden, damit ein Restore Vorgang so unkompliziert wie nur möglich ist.

Trotzdem ist der erste Punkt der relevante. Egal was wir hier machen, solange an einem Punkt ein Kennwort übertragen werden muss, ist es auch irgendwo in Klartext vorhanden. Jegliche Verschlüsselung davor ist nur Augenwischerei und bietet für jemanden der euer Kennwort haben will, keinerlei echte Sicherheit.

Die echte Sicherheit fängt bei euch an: Zugriff zum Server korrekt abschotten. Backups nicht irgendwo rumfliegen lassen.

paresy

Dass das Kennwort während der Skriptlaufzeit dann in Klartext im Speicher liegt ist mir schon klar, aber ansonsten liegen die Passwörter dann verschlüsselt auf der Festplatte und sind nicht einfach lesbar für jedermann…

Nehmen wir als Beispiel doch mal ein FTP Programm…da gibt man seine Zugangsdaten zu den FTPs doch auch in eine Maske ein und speichert die dann im Programm ab und die sind nicht direkt per Klartext lesbar. Ja die kann man meist auch irgendwie auslesen, aber sie stehen nicht im Klartext gesammelt in einer Datei.

Entweder denke ich total wirr, oder ihr versteht mich nicht, oder keine Ahnung :smiley:

Ich sehe schon, ich muss mir selbst was nach meinen Vorstellungen bauen :slight_smile: Falls doch noch jemand Interesse/Ideen hat in der Richtung etwas zu machen, ihr wisst wie ihr mich erreicht :wink:

Grüße,
Chris

bei ein paar wirklich relevanten Keys mache ich es so das ich mir eine get-Funktion in meinem eh vorhandenen Helferscript (extern mit Include) angelegt habe. Woher das Script dann die Daten bekommt kann sich ja jeder selber überlegen. Da ich die Daten immer „nur“ in Scripten benötigt habe hat es bislang ausgereicht.

@Bayaro

Der FTP Server benötigt das Passwort aber nicht im Klartext. Der FTP Server bekommt das Passwort im Klartext und „verschlüsselt“ es mittels einem Hashalgorithmus (One-Way) und vergleicht das Ergebnis mit dem „verschlüsselten“ Passwort auf der Festplatte. Der Symcon braucht aber das Passwort weil er sich damit gegen einen fremden Dienst anmelden muss. Somit ist es wie paresy schon gesagt hat nur augenwischerrei. Einzig die Eingabe eines Passwort beim Starten wäre ein wirklicher Sicherheitsgewinn, aber auch ein maximaler Komfortverlust.

Entweder reden wir noch aneinander vorbei, oder ich denke an etwas, dass es nicht gibt :smiley:

Ich denke ich verstehe was du mir sagen willst, aber ich denke auch, dass keiner bisher zu verstehen scheint, was mein Anliegen ist :smiley: Ich will die Passwörter nicht im Klartext rumliegen haben. Punkt.
Wenn einer einen Crypto-Key klaut und damit meine Passwort-Datei entschlüsselt, dann ist das so. Aber der „Normalfall“ mit „abgrasen durch Bot nach PWs“ ist damit „weg“ und damit für mich eine Stufe Sicherheit mehr :slight_smile: Und ja, ich kenne und verwende so Dinge wie VPN, Sophos UTM und Co :wink:

Aber wie auch immer, ich werde eine für mich akzeptable/passende Lösung finden und umsetzen :slight_smile:

Grüße,
Chris

Datenbanken wie Oracle, Mysql etc. wolle ihre Passwörter im Klartext bei der Anmeldung haben, nix Hash oder Kerberos oder so ein Luxus. Deswegen muss man sie aber auch nicht im Klartext in den Scripten stehen haben. Klar kann man das Passwort bekommen, wenn man den Algorithmus und die Pfade kennt, aber absolute Sicherheit ist auch nicht das Ziel, sondern die Latte um einiges höher zu legen. Und glaub mir, wenn jemand schnell die Passwortdatei kopiert hat, wenn er Zeit hat den Code zu analysieren auch noch das Entschlüsselungsscript dazu und es trotzdem nicht entschlüsselt bekommt, weil er noch einen extra Key braucht, der nur auf dem originalen System liegt ist das für 99% der Angreifer schon zu viel Arbeit. Das restliche Prozent bekommt sowieso immer alles, wenn sie es darauf anlegen. Dann sind die IPS Daten aber wohl das geringste Problem.

Jeder darf natürlich für sich entscheiden, wie viel er an Aufwand reinsteckt um sein persönliches Security-Wohlfühl-Niveau zu erreichen.

Von einem Softwareanbieter erwarte ich aber auch, das er nicht leichtfertig die Passwörter der Kunden präsentiert. In vielen großen Firmen sind Passwörter im Klartext per Compliance-Richtline sogar verboten, da winkt dann schon der Einkauf ab. Es wäre doch ein leichtes, zumindest irgendeine proprietäre Obfuscation in den Binär-Code einzubauen und damit das bei der Installation das übergebene Passwort vor dem Abspeichern so zu verfremden, das es nicht mehr wie ein Passwort aussieht und man länger als 1Std. braucht, um es zu analysieren.

My 2 Cents
Tommi

Juhu, ich bin nicht allein und es gibt doch Menschen die mich verstehen :slight_smile: :cool: Danke für deine Ausführungen Tommi! :slight_smile:

Grüße,
Chris

Und noch jemand der meine Bedürfnisse zu teilen scheint :slight_smile:
Passwort mit openssl verschlüsseln?

@paresy: Kann man nicht evtl. doch direkt in IPS eine Möglichkeit anbieten? Ich würde das als zusätzlichen Kaufgrund für Leute sehen und nicht als „Augenwischerei“. Aber wir hatten ja bereits alle schon unsere Ausführungen dazu :slight_smile:

Grüße,
Chris

Es bleibt halt Augenwischerei wenn man das Passwort nicht beim start eingibt, auch wenn ihr es nicht so empfindet. Und ich hoffe, dass es nicht integriert wird, da es normale Menschen glauben das Sie dadurch mehr Sicherheit haben, was faktisch falsch ist!

Ärgerlich ist es halt, dass der Ruf nach solchen pseudo Lösungen immer häufiger wird, weil die Leute keine Ahnung von Sicherheit/Kryptographie haben und dann nach Verschlüsselung schreien.

Aber Ihr könntet euch ja eine kleine Passwortverwaltung in PHP bauen, und in euren Script diese dann verwenden. Hier ein Link zu einer PHP Funktion mit der man die Daten nach ROT13 verschlüsselt.

PHP: str_rot13 - Manual

Da ist auch eine in PHP umgesetzte Version enthalten, falls die Funktion selber nicht von IPS angeboten wird.

Ja, ich bin kein Krypto-Profi wie du es ja einer zu sein scheinst, bin aber auch kein Total-Noob wie du es versuchst darzustellen. Und es ist auch keine „Pseudo-Lösung“, sondern eine Lösung für meinen Anwendungsfall/Wunsch und auch von anderen. Weil es eben doch ein Gewinn an Sicherheit ist, auch wenn nur ein kleiner. Oder von mir aus nennen wir es ab jetzt einfach „Gewinn an Erschwerung der Passwortauslesung“, wenn dich das zufrieden stimmt? :rolleyes:

Ich wiederhole mich ungern nochmal > es geht mir nicht darum, meine Passwörter komplett crypted irgendwo abzulegen und alles total zu verschlüsseln. Es geht ja immerhin nur um mein LAN, welches meiner Meinung nach gut abgesichert ist. Sondern es geht darum, dass die Passwörter nicht im Klartext auf der Festplatte rumliegen zu lassen. Das die trotzdem im Klartext während der Skriptlaufzeit im Speicher sind weiß ich und ist mir egal. Und auch das man meine Passwörter kinderleicht entschlüsseln kann - WENN man sich nur ein wenig Mühe macht - aber kein Bot oder sonstwas würde sich die Mühe machen! Also ist es ein „Gewinn an Erschwerung der Passwortauslesung“!

Und nur etwas nicht einbauen, weil jemand es falsch verstehen könnte??? :rolleyes:

Danke für den Link zu str_rot13, werde ich mir mal anschauen. 13 Buchstaben verschieben wäre ein Anfang, aber da geht sicher noch mehr. Auch wenn es reichen würde, weil es wie gesagt nur um das einfache Klartext abspeichern verhindern geht.

In diesem Sinne, ich freue mich auf weitere Beiträge ZUR LÖSUNGSFINDUNG zum Thema „Gewinn an Erschwerung der bot-automatisierten Passwortauslesung“ :slight_smile:

Grüße,
Chris

Ich wollte mich ja eigentlich raushalten, da die Diskussion eher wenig zielführend ist, aber

Wenn dein LAN und somit natürlich auch die Maschine, auf der IPS läuft „gut abgesichert“ ist, dann sind doch alle notwendigen Grundlagen gelegt um die settings.json zu schützen.

[ul]
[li]Kein Unberechtigter kommt an den Rechner[/li][li]Keine Sharezugriffe auf das IPS Verzeichnis bzw. die Maschine[/li][li]Kein „überflüssigen“ Services auf der Maschine, die das Risiko eines Fremdzugriffs erhöhen[/li][li]Virenschutz[/li][li]Regelmäßige PW Änderung des/der Accounts auf der Maschine[/li][li]spezielle Postfächer, etc. für IPS nutzen[/li][li]„kein“ direkter Zugriff aus dem Internet/unsicheren Netzen[/li][li]…[/li][li]ließe sich noch um einige Punkte ergänzen[/li][/ul]

Wenn du also die oben genannten Beispiele umgesetzt hast und ein " meiner Meinung nach gut abgesichert"es LAN hast, wie sollte dann ein Bot auf deine Maschine kommen und ausgerechnet die settings.json suchen um dort PWs zu finden.

Bzw. wer außer dir sollte auf der Maschine entsprechende Rechte haben, um dort für Security-Probleme zu sorgen.