[PATCH] fhem.pl - Veränderung eines Attribut Values durch AttrFn

[Markus Bloch]

Nunja, die FritzBox benötigt auf dem Telnet-Prompt das Klartextpasswort. Von daher komm ich hier nicht drum rum, das Klartextpasswort direkt zu benutzen.

Der User hat nachwievor mehrere Möglichkeiten, unter anderem auch das Passwort in einer Datei zu speichern.

Wenn keiner Einwände gegen die xor-Funktionen hat, würde ich die gerne die Tage in 99_Utils.pm einchecken.

Viele Grüße

Markus

[tupol]

Nunja, die FritzBox benötigt auf dem Telnet-Prompt das Klartextpasswort. Von daher komm ich hier nicht drum rum, das Klartextpasswort direkt zu benutzen.

Der User hat nachwievor mehrere Möglichkeiten, unter anderem auch das Passwort in einer Datei zu speichern.

Wenn keiner Einwände gegen die xor-Funktionen hat, würde ich die gerne die Tage in 99_Utils.pm einchecken.

Nur um uns nicht mißzuverstehen. Ich würde gerne eine Funktion haben, die das Paßwort gleich verschlüsselt in einer Datei speichert und dann wieder entschlüsselt für die Benutzung. Dann gibt es keine Probleme mit Attributen.

[betateilchen]

Wenn keiner Einwände gegen die xor-Funktionen hat, würde ich die gerne die Tage in 99_Utils.pm einchecken.

Dagegen, weil Fritzkotz-spezifisch. Deshalb sollte sowas allenfalls in die Fritzkotzutils.pm

[justme1968]

das ist nicht fritzbox spzifisch sondern für jedes modul das accounts und passwörter verwendet nützlich.

von httpmod über netatmo, withings, mailcheck, GDS, ipcam, ... gibt es sicher 10 oder 15 module die das betrifft und nur eines hat mir der fritzbox zu tun.

[Markus Bloch]

Nur um uns nicht mißzuverstehen. Ich würde gerne eine Funktion haben, die das Paßwort gleich verschlüsselt in einer Datei speichert und dann wieder entschlüsselt für die Benutzung. Dann gibt es keine Probleme mit Attributen.

Passwort Verschlüsseln ist doch nur eine Möglichkeit. Ich finde es falsch die Verschlüsselung direkt nur für diesen spezifischen Fall anzuwenden. Vielleicht will der User ja auch was direkt in Perl Verschlüsseln oder weiß der Kuckuck was.

Ich hab nichts dagegen diese xor-Funktionen in einer neuen Funktion zu verwenden die dein Anwendungsszenario umsetzt (String => verschlüsseln => auf Platte schreiben).

[betateilchen]

Solange aber der $key irgendwo in der fhem Konfiguration zu finden ist, ist das Ganze doch ziemlich sinnlos.

Und die uniqueID finde ich auch recht fragwürdig, weil es die erstens nicht in jeder fhem Installation geben muss und zweitens 99,9% aller User nicht daran denken dürften, diese ID irgendwann irgendwo tatsächlich zu sichern.

[Markus Bloch]

Deswegen ja: http://forum.fhem.de/index.php/topic,30528.0.html

[rudolfkoenig]

Folgendes faellt mir dazu ein:
- das eigentliche Problem ist, dass Leute beim Posten der fhem.cfg sorglos sind.
- ein verschleiertes Passwort suggeriert dem Benutzer, dass das hoch-sicher ist, und es niemand knacken kann, was prinzipiell nicht richtig ist, weil das Programm es in Klartext braucht.
- falls jemand sein uniqueid postet, oder fhem.de geknackt wird, dann kann man gepostete verschluesselte Passwoerter entschluesseln.
- falls alle Passwoerter in FHEM mit dem uniqueid verschluesselt werden, und ein Teil bestimmter Passwoerter im Klartext bekannt ist , weil einer der Module einen festen Prefix wie MyModuleName: verwendet, dann sind alle anderen mit dieser Methode verschleierten Passwoerter gefaehrdet.
- falls das uniqueid verlorengeht, dann muessen die Leute das Passwort neu setzen. Das Modul sollte dafuer sorgen, dass das auffaellt, sonst gibt es wieder unnoetige Supportanfragen.

Die Frage, was ich mir stelle ist, was ist besser: ein Ratschlag and die Benutzer, dass man Passwoerter nicht posten sollte, oder eine bekannt problematische Hilfestellung vom FHEM-Framework (die man Schrittweise verbessern koennte), was von den Entwicklern einiges an Aufwand verlangt, und nie perfekt sein wird, aber immer noch besser ist, als auf "vernuenftige" Benutzer zu hoffen. Leider bekommen damit "vernuenftige" Benutzer einige Probleme, die sie ohne Verschleierung nicht haetten.

Das ist keine rhetorische Frage, ich bin unentschlossen.

[betateilchen]

Die Frage, was ich mir stelle ist, was ist besser:

Ich denke gerade darüber nach, für meine Module künftig ein Attribut "credentials" einzuführen, das lediglich eine uuid enthält, unter der in der configDB die zugehörigen Zugangsdaten  user und password gefunden werden können. Dieses Attribut kann natürlich nur verwendet werden, wenn das fhem auch mit configDB arbeitet.

Natürlich ist auch das kein 100% Schutz, aber erstens ist die Wahrscheinlichkeit, dass eine komplette Konfigurationsdatenbank geklaut wird, sehr gering und zweitens reden wir hier generell nicht über Onlinebanking oder andere - wirklich - sicherheitskritische Anwendungen. Die Forderung, Zugangsdaten nicht mehr im Klartext in der laufenden Konfiguration finden zu können, wäre damit jedenfalls erfüllt.

[rudolfkoenig]

Falls du dafuer FileRead/FileWrite verwendest (am besten in einer zentralen Funktion), dann wuerde das auch ohne configDB funktionieren.

[betateilchen]

ja, und wenn Du die fhem.cfg abschaffen würdest...

(man darf ja in der Weihnachtszeit auch mal Wünsche haben...)

Ich werde in diesem Leben nicht mehr damit anfangen, Datenbankstrukturen in Textfiles abzubilden, insofern sind FileRead/FileWrite für mich der falsche Ansatzpunkt, auch wenn ich Dein Ansinnen nachvollziehen kann. Ausserdem stellt configDB jetzt schon einen Grundstock der für meine Idee benötigten Funktionalitäten bereit.

[tupol]

- das eigentliche Problem ist, dass Leute beim Posten der fhem.cfg sorglos sind.
...
Die Frage, was ich mir stelle ist, was ist besser: ein Ratschlag and die Benutzer, dass man Passwoerter nicht posten sollte, oder eine bekannt problematische Hilfestellung vom FHEM-Framework (die man Schrittweise verbessern koennte), was von den Entwicklern einiges an Aufwand verlangt, und nie perfekt sein wird, aber immer noch besser ist, als auf "vernuenftige" Benutzer zu hoffen. Leider bekommen damit "vernuenftige" Benutzer einige Probleme, die sie ohne Verschleierung nicht haetten.

Das ist keine rhetorische Frage, ich bin unentschlossen.

Das Problem ist also die Ablage in den Attributen. Die Lösung wäre die Ablage in einer Datei, welche durch ein "Set ... password" geschrieben wird. Wenn das Framework durch ein Passwort-Schreib-Funktion und einer Lese-Funktion ähnlich der Attributfunktion ergänzt wird, ist der Aufwand für Entwickler fast Null.

PS: Das Wort "vernünftige" Benutzer gibt es im Human Factor Engineering nicht

[justme1968]

genau so hatte ich es ja weiter vorne schon mal vorgeschlagen. ein mini 'api' um ein password zu setzen und wieder zu bekommen ohne das es im device gelistet wird. ob das in der db oder in einem file oder sonst wo landet sollte dabei völlig egal sein.

wie wäre es mit

storePassword($key,$password)
$password = queryPassword($key)

$key wäre dann modulspezifisch eine uuid oder der device name oder was auch immer um das password zu identifizieren.

intern kann das ein einfacher hash sein der bei save per Data::Dumper in ein file geschrieben wird und beim start per eval gelesen wird oder auch in der configDb landet.

[tupol]

Ja so passt es. Nur das save sollte möglichst nicht notwendig sein. Es muss jedes Mal sofort speichern. Über $key könnte man dann auch innerhalb eines Moduls mehrere Passwörter anlegen. Allerdings sollte es für jedes Modul einen reservierten Bereich geben, damit nicht jeder Modulauthor darauf achten muss, was der andere gerade als $key verwendet.

[Markus Bloch]

Neuer Vorschlag:

Voraussetzungen sind die beiden xor-Funktionen, sowie die getUniqueId() Funktion aus http://forum.fhem.de/index.php/topic,30528.0.html


$err = storePassword($key, $password);

Code Auswählen Erweitern


sub storePassword($$)
{
  my ($key, $pass) = @_;
  my $passwdFile  = $attr{global}{modpath}."/FHEM/FhemUtils/passwd";
  my %passwdList = ();
 
  if(-R $passwdFile)
  {
    my ($err, @lines) = FileRead($passwdFile);
   
    return "error while reading passwd file - $err" if(defined($err));
   
    foreach (@lines)
    {
        my $line = $_;
       
        $line = xor_decode($line, getUniqueId());
        next unless($line =~ /^[^|]+\|[^|]+$/);
     
        my ($tmpKey, $tmpPass) = split(/\|/, $line);
        $passwdList{$tmpKey} = $tmpPass;
    }
  }
 
  $passwdList{$key} = $pass;
 
  my @string;
 
  while (my ($key, $value) = each(%passwdList))
  {
    push(@string, xor_encode($key."|".$value, getUniqueId()));
  }
 
  return FileWrite($passwdFile, @string);

}


($err, $password = queryPassword($key);

Code Auswählen Erweitern


sub queryPassword($)
{
  my ($key) = @_;
  my $passwdFile  = $attr{global}{modpath}."/FHEM/FhemUtils/passwd";
  my %passwdList = ();
 

    my ($err, @lines) = FileRead($passwdFile);

    return ("error while reading passwd file - $err", undef) if(defined($err));

    foreach (@lines)
    {
        my $line = $_;
       
        $line = xor_decode($line, getUniqueId());
        next unless($line =~ /^[^|]+\|[^|]+$/);
     
        my ($tmpKey, $tmpPass) = split(/\|/, $line);
        $passwdList{$tmpKey} = $tmpPass;
    }
 
 
  return (undef, $passwdList{$key}) if(exists($passwdList{$key}));
  return ("no password stored", undef);

}