FR Modul Traffic - API-Key in Key-File speichern

[Felix_86]

Hallo zusammen,

im Rahmen der aktuellen Diskussionen und Themen rund um das Weather-Modul und dem Wechsel von der Yahoo API zur OpenweatherMap API oder Darksky API kam die Anmerkung zur Speicherung des API-Key im Key-File anstatt in der Device Definition auf.

Da auch das Traffic Modul einen API Key erfordert, stellt sich mir hier die gleiche Frage, ob der API-Key nicht als "sensibles" Datum (ähnlich wie Login-Credentials) aus dem Device herausgehalten werden sollte?
Sprich, die Verwaltung mittels setKeyValue und getKeyValue im Key-File, so wie auch das FritzBox Passwort im entsprechenden Modul gespeichert wird.

Anbei ein List meines Traffic Device:

Code Auswählen Erweitern

Internals:
   APIKEY     4711
   DEF        4711
   INTERVAL   3600
   NAME       Google.Traffic
   NR         293
   STATE      disabled
   TRIGGERTIME 1547741178.50214
   TRIGGERTIME_FMT 2019-01-17 17:06:18
   TYPE       TRAFFIC
   VERSION    1.3.7
   READINGS:
     2019-01-19 11:04:37   state           disabled
   helper:
Attributes:
   disable    1
   end_address zu hause
   outputReadings text
   room       Verkehr
   start_address lummerland
   userattr   disable end_address outputReadings start_address verbose
   verbose    1

Man kann ja mal darüber nachdenken und in einer Folgeversion dieses Sicherheitsfeature einbauen.

Besten Dank.

[jmike]

Hi.

Jop, gute Idee. Ich werd's umsetzen.

[PatrickR]

Hi!

Auf die Gefahr hin, jetzt einen dicken Fettnapf anzusteuern: Ich halte den Ansatz mit dem "Keyfile" aka uniqueID für fragwürdig.

1.) Es erhöht die Sicherheit nicht. Es ist schlichtweg Security by Obscurity.
2.) Einer der Hauptvorteile von FHEM ist, dass die vollständige Konfiguration in der fhem.cfg liegt. Das erlaubt einfache, schnelle und robuste Backups. Die uniqueID ist hier eine Ausnahme. Sie ist am hintersten Ende des Dateisystems versteckt und trägt einen Namen, der ihre Wichtigkeit vollständig verschleiert. Sie lässt sich nicht einmal durch Konfigurationsoptionen an einen sinnvollen Ort des Dateisystems verlegen. (Symlinks etc. mal ausgenommen).

Ich glaube, FHEM ist das falsche System, um Nutzer vor sich selbst zu schützen und die dadurch entstehende Offenheit macht für mich gerade den Reiz von FHEM aus. Möchte man dennoch verhindern, dass Nutzer beispielsweise Zugangsdaten aus list ins Forum pasten, wäre der sinnvollere Ansatz m. E., die kritischen Attribute/Internals durch den Modulentwickler markierbar zu machen und bei list zu maskieren.

Patrick

[JoWiemann]

Schützenswerte Zugangsdaten haben in einer Weboberfläche maximal nur während der Eingabe etwas zu suchen. Ansonsten dürfen sie nur durch die Applikation auf dem Server genutzt werden. Wo die Zugangsdaten dann persistent und hoffentlich verschlüsselt abgelegt werden ist eigentlich egal. Und, streng genommen müssen/dürfen sie auch nicht in einem Back-Up, Log, List und Json landen, sondern gehören in einen digitalen Tresor. Bei Wiederherstellung des Systems ist es immer sicherer sie neu einzugeben.

Grüße Jörg


Gesendet von iPhone mit Tapatalk

Grüße Jörg

[PatrickR]

Hallo Jörg!

Schützenswerte Zugangsdaten haben in einer Weboberfläche maximal nur während der Eingabe etwas zu suchen.

Geschenkt, Umsetzung wäre analog zu meinem Vorschlag mit list.

Ansonsten dürfen sie nur durch die Applikation auf dem Server genutzt werden.

Die Forderung ist nicht wirksam umsetzbar. fhem.pl kann darauf zugreifen, also kann es jeder mit Vollzugriff auf FHEM, und selbst wenn man FHEM vollständig abriegeln würde (was vermutlich nie geschehen wird) zumindest jedoch der Administrator des Servers.

Wo die Zugangsdaten dann persistent und hoffentlich verschlüsselt abgelegt werden ist eigentlich egal.

Wie ich oben geschrieben habe, ist das wo nicht egal. Sie sind für den FHEM-Betrieb relevant und sollten daher nicht versteckt werden. Verfügbarkeit ist wichtig.

Und, streng genommen müssen/dürfen sie auch nicht in einem Back-Up, Log, List und Json landen, sondern gehören in einen digitalen Tresor.

Zum Log: Sehe ich wie Du. Das mit dem digitalen Tresor ist eine wünschenswerte Forderung, die jedoch nicht umsetzbar ist. fhem benötigt die Daten zur Laufzeit und somit muss es selbst in der Lage sein, sie zu entschlüsseln. Jetzt könnte man natürlich beim FHEM-Start eine Passworteingabe verlangen, aber selbst dann wären die Daten während des laufenden Betriebs im Hauptspeicher. Ich hoffe, Du meinst mit verschlüsselt nicht Kodierung wie base64 oder die Verschlüsselung mit einem irgendwo anders auf oder in dem System versteckten Schlüssel. Das ist keine Verschlüsselung sondern Obfuscation.

Bei Wiederherstellung des Systems ist es immer sicherer sie neu einzugeben.

... und natürlich bei jedem Start des FHEM-Dienstes bzw. bei jedem Reconnect der Dienste, die die Zugangsdaten benötigen. Sonst wäre auch diese Forderung vollständig unwirksam.

Patrick

[JoWiemann]

Ok, mein Fehler. Unklar ausgedrückt.

"Ansonsten dürfen sie nur durch die Applikation auf dem Server genutzt werden."

Hiermit war gemeint, dass sie, auch nicht ihr verschlüsseltes Ergebnis, nicht mehr auf einer Weboberfläche, GUI usw. auftauchen sollen. Dass ich als Berechtigter oder Eindringling immer irgendwo die Zugangsdaten finden werde. Das ist so. Also wenn ich sie finde, dann so verschlüsselt, dass der Entschlüsselungsaufwand sehr hoch ist. MD5 ist hier denkbar schlecht. Das entschlüsselt ja schon jede Suchmaschine...

"... sondern gehören in einen digitalen Tresor."
Hiermit war gemeint, dass die Zugangsdaten auf einem anderen Medium verschlüsselt abgelegt sind. Also zum Beispiel in einem Zugangsdaten-Manager. Bei näherem Nachdenken. Eigentlich wäre etwas vergleichbares für Fhem nicht schlecht.

Und eigentlich gilt wie immer: Ein System ist nur so sicher, wie das Aufwand/Nutzen Verhältnis möglichst unattraktiv ist. Vergleichbar mit Wohnungen. Verhindern wirst Du es nicht, aber Du kannst es unattraktiv machen.

Und, die Diskussion führen auch im Unternehmen in der Group Security. Welche Vorgaben machen wir für "Sichere Softwareentwicklung". Ist immer spannend in den Workshops.

Grüße Jörg

[Dr. Boris Neubert]

Der Vorteil von Schlüsseln in Dateien ist, dass der unvorsichtige User sie nicht versehentlich hier im Forum postet, wenn er nach Log oder Konfiguration gefragt ist. Ansonsten ist Sicherheit bei FHEM nur rudimentär verfügbar.

Grüße
Boris

[rudolfkoenig]

Ansonsten ist Sicherheit bei FHEM nur rudimentär verfügbar.

Wie wuerde eine nicht rudimentaere Loesung ausschauen?

[JoWiemann]

Ansonsten ist Sicherheit bei FHEM nur rudimentär verfügbar.

Hm, mir würde es schon helfen wenn Zugangsdaten, die Fhem benutzt, möglichst sicher abgelegt sind. Diese Zugangsdaten stellen für mich das höhere Risiko dar.

Grüße Jörg

[PatrickR]

Hallo Boris!

Der Vorteil von Schlüsseln in Dateien ist, dass der unvorsichtige User sie nicht versehentlich hier im Forum postet, wenn er nach Log oder Konfiguration gefragt ist.

Deshalb wehre ich mich ja garnicht dagegen, sie an Stellen mit dem stärksten Fehlerpotenzial auszublenden, nämlich z. B. list und in den Device-Details. In Logs haben sie natürlich auch nichts zu suchen. Beim Klicken der relevanten Attribute bzw. DEF/defmod sollten sie aber sichtbar sein, um die Konfigurierbarkeit zu gewährleisten.

Ich finde generell den Ansatz schick, dass die fhem.cfg alle relevanten Konfigurationseinstellungen konzentriert (ja ich weiß, das trifft nur zu 95% zu). Das erlaubt unix-like einfache und konsistente Snapshots, auch ohne configDB.

Zum Ansatz der uniqueID: Das größe Problem ist m. E. nicht die Nutzung der Datei selbst sondern Name und Ort der Datei. Mir ist bewusst, dass Name und ggf. der Ort historische Gründe haben und letzterer vielleicht auch verhindern soll, dass Nutzer an der uniqueID (also dem Feld) basteln. Ärgerlicherweise kommt hinzu, dass man zwar den Namen der Datei ändern kann, nicht aber den Ort. Dort entsteht der Eindruck, die Sicherheit solle durch dadurch erhöht werden und man gehe von einer tatsächlichen Wirksamkeit aus.

Ansonsten ist Sicherheit bei FHEM nur rudimentär verfügbar.

Ich würde es anders ausdrücken: FHEM ist ein gewachsenes System, dessen Schwerpunkt nicht von Anfang an auf Sicherheit lag. Man darf aber auch nicht verkennen, dass hier einiges passiert ist (schrittweiser Ausbau von allowed, forbiddenroom oder CSRF-Tokens), auch wenn die Nachrüstung schwierig ist. Hinzu kommt, dass über diverse Module, telnet oder die Textbox in FHEMWEB beliebige Befehle mit den Rechten (System-FHEM-)Users ausführbar sind. Das ist definitiv ein Feature, aber erhöht nicht gerade die Sicherheit.

Hm, mir würde es schon helfen wenn Zugangsdaten, die Fhem benutzt, möglichst sicher abgelegt sind. Diese Zugangsdaten stellen für mich das höhere Risiko dar.

Das Problem ist, dass ein einigermaßen wirksamer Schutz (Du sprachst von Verschlüsselung) nicht möglich ist, lediglich Gewissensberuhigungsmaßnahmen wie das Verstecken oder Obfuscation (inkl. symmetrische Verschlüsselung mit im System verfügbaren Schlüssel).

Patrick

[rudolfkoenig]

Das Problem ist, dass ein einigermaßen wirksamer Schutz (Du sprachst von Verschlüsselung) nicht möglich ist [...]

"nicht möglich" ist hart formuliert, ich wuerde stattdessen "ich kenne keine, die im FHEM-Umfeld sinnvoll praktikabel ist" dazu sagen.

Z.Bsp. koennte man uniqueId verschluesseln, und nach dem FHEM-Start muss der Benutzer das Passwort eingeben, solange koennen Module nicht auf die gespeicherten Daten zugreifen. Aber man muss auch fragen, welche Angriffszenarien verhindert man damit, und ob Benutzer bereit sind, die Nachteile in Kauf zu nehmen.

Ich meine der Aufwand ist den Sicherheitsgewinn nicht Wert.
Wer bessere Ideen hat...