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

[justme1968]

mir ging es weniger um das list absetzen können (das lässt sich z.b. über allowed commands einschränken) sondern darum die list ausgabe einfach zum debuggen hier anhängen oder sonst wie weiter geben zu können. z.b. auch per screenshot. und das geht weder mit einem password im klartext noch mit einem nur durch das modul verschleierten password sondern nur wenn es tatsächlich mit einem einmaligen schlüssel verschlüsselt ist der nicht im modul kodiert ist. d.h. der anwender muss den schlüssel setzen könen -> henne/ei problem.

die frage ist wie wichtig diese passwörter sind. aber wenn man sich schon gedanken macht kann man es auch gleich zu ende denken.

fürs verstecken reicht vielleicht auch schon ein reading mit einem . so das es im list nicht auftaucht.

geht das mit dem . eigentlich auch für attribute? dann könnte man ein normales attribut 'password' zum setzen verwenden, das password in einem attribut '.password' ablegen und 'password' auf <gesetzt> ändern.

wie wichtig ist es das man das gesetzte password doch auf irgendeine art wieder im klartext anzeigen kann?

gruss
  andre

[betateilchen]

Ich finde, wegen einem solchen Krampf sollte man eine so zentrale Funktion wie die AttrFn nicht verhackstücken.

Grundsätzlich wäre eine fhem-weite Lösung für Passwörter sicher denkbar und wünschenswert, aber die Attribute sehe ich dabei als den falschen Ansatzpunkt.

[justme1968]

das oben mit dem .password war nicht der vorschlag für die zentrale lösung und auch nicht wie es in AttrFn eingebaut werden sollte sondern eine idee wie man es in einem modul machen kann so lange es die zentrale lösung nicht gibt.

[herrmannj]

in diesem Bezug stellt das Konzept ja keine echte Sicherheit dar - die lässt sich so auch nicht erreichen. Das Passwort muss (vom Modul) in Klartext zurückgerechnet werden - sonst kann die fb ja nicht prüfen. Alle Einwegfunktionen (mit denen man Sicherheit erreichen könnte) funktionieren nur wenn Du lokal prüfst.

@Markus
Mal was anderes, gibst Du dem modul mehr mit ? Der Ansatz scheint ja tauglich zu sein generell Funktionen die nur auf der FB laufen aufzunehmen und das "Manko" des fehlenden Autostarts für fhem auf der fb  durch ein Modul zu lösen was dann, so wie von Die beschrieben, von fhem auf der fb gestartet wird.

vg
jörg

[justme1968]

eben. so lange das password wieder in klartext zurück verwandelt werden muss ist die einzige 'sicherheit' das verstecken.

das verschleiern reicht nicht bzw. die verschleierte version müsste genau so versteckt werden. oder es braucht einen 'echten' installationsspezifischen schlüssel und dann muss der versteckt werden.

wie man es dreht und wendet ist ein sichtbares attribut nicht geeignet zum verstecken.

[herrmannj]

naja, ich würde mich auch wohler füllen wenn das wenigstens nicht auf dem Silbertablett im attrib steht. 

vg
jörg

[Markus Bloch]

Generell war meine Idee das Passwort mit der uniqueId aus fheminfo zu verschlüsseln, die ja jedes FHEM System besitzen sollte (attr global uniqueID). Damit kann das Passwort durchaus preisgegeben werden, und selbst in einem list Output wäre das Passwort von anderen nicht ohne "kriminellen Aufwand" decodierbar.

Das Modul FRITZBOX macht ja etwas sehr ähnliches. Dort wird das Passwort ausschließlich in einer Datei gespeichert. Das finde ich als Einsteiger aber etwas kompliziert. Ich möchte beides anbieten, einmal das direkte setzen via Attribut (durch direktes unkenntlich machen) als auch optional als externe Datei, wo der Pfad im gleichen Attribut gesetzt werden kann.

@Jörg: Nunja, ich will auf der FritzBox nur via telnet das Telefonbuch einlesen (cat /var/flash/phonebook)

[herrmannj]

@Jörg: Nunja, ich will auf der FritzBox nur via telnet das Telefonbuch einlesen (cat /var/flash/phonebook)

ach komm, wenn Du einmal dabei bist 

[justme1968]

das mit der uniqueId ist eine gute idee. so macht es sinn.

wie wäre es die funktionen zum ver- und entschlüsseln mit der uniqueId gleich allgemein zu machen rudi für die allgemeine 99_Utils.pm vorzuschlagen?

[Markus Bloch]

wie wäre es die funktionen zum ver- und entschlüsseln mit der uniqueId gleich allgemein zu machen rudi für die allgemeine 99_Utils.pm vorzuschlagen?

An nichts anderes hätte ich da auch gedacht 

Man müsste sich nur auf ein Verfahren einigen.

[justme1968]

dann wird ja doch noch alles gut

die randbedingung ist vermutlich das es ohne zusätzliche perl module auskommen soll und  schlank und schnell sein soll.

[Markus Bloch]

Ich würde RC4 vorschlagen, finde allerdings keine direkte Implementation als einzelne Perl Funktion. Das Modul Crypt::RC4 ist ein reines Perl-Modul, aber auf objekt-orientierter Basis gestaltet.

Desweiteren gibt es von einigen Universitäten eine Implementation mit STDIN => STDOUT: http://pi4.informatik.uni-mannheim.de/pi4.data/content/projects/cryptography/rgp/rc4/rc4c.html

Unter http://www.tek-tips.com/viewthread.cfm?qid=320118 habe ich eine sub RC4() gefunden, weis aber nicht, ob die dem Standard entspricht, was den Algorithmus angeht.

Evtl. andere Vorschläge?

Gruß
Markus

[rudolfkoenig]

Ich bin zwar kein Kryptologe, aber wage zu behaupten, dass in diesem Fall (d.h. Klartext und Geheimschlussel sind beide unbekannt, und Klartext ist kuerzer als der Geheimschluessel), reicht den Klartext auf die Laenge der Schluessel zu verlaengern, und ihn per XOR zu "verschluesseln".
Man bedenke: es geht darum, Passwoerter nicht versehentlich im Klartext zu posten. Und wenn jemand scharf auf entschluesseln ist, kann auf fhem.de einbrechen, und alle unique-id's durchtesten. Da hilft auch kein RC4.
Und wer Sicherheit haben will, der passt beim Posten auf.

[Markus Bloch]

Ich würde folgende Funktionen für die 99_Utils.pm vorschlagen:

Code Auswählen Erweitern



sub xor_encode {
    my ($str, $key) = @_;
    $key = Digest::MD5::md5_hex(unpack "H*", $key);
    $key .= Digest::MD5::md5_hex($key);

    my $enc_str = '';
    for my $char (split //, $str){
       
        my $encode = chop $key;
     
        $enc_str .= sprintf("%.2x", ord($char) ^ ord($encode ));
        $key = $encode . $key;
    }
   return $enc_str;
}


Code Auswählen Erweitern


sub xor_decode {
    my ($str, $key) = @_;
    $key = Digest::MD5::md5_hex(unpack "H*", $key);
    $key .= Digest::MD5::md5_hex($key);

    my $dec_str = '';
    for my $char (map { pack('C', hex($_)) } ($str =~ /(..)/g)){
       
        my $decode = chop $key;
       
        $dec_str .= chr(ord($char) ^ ord($decode));
        $key = $decode . $key;
    }
   return $dec_str;
}


Beispiel:

Code Auswählen Erweitern

{xor_encode("test","mysupersecretkey")}  =>  "44544b10"
{xor_decode("44544b10","mysupersecretkey")}  => "test"


[tupol]

Das mit den Attributen ist mir nicht geheuer. Mir wäre es am liebsten, wenn ich für jedes Define die Möglichkeit hätte, eine Datei in einem zentralem Verzeichnis auf dem Server abzulegen. Dort kann man dann z.B. das Passwort verschlüsselt hinterlegen. Das Anlegen der Datei (sprich die Paßworteingabe) müsste einmalig über das Modul (set <name> password ***) erfolgen.

PS: Openweather (Wetter.Com) nutzt MD5.