Hallo Rudi,
anbei ein kleiner Patch, der es einer AttrFn ermöglicht den zu prüfenden Wert optional zu verändern.
Das bedeutet im Detail, dass die AttrFn optional als Return Value zwei Werte übergeben. Der zweite Wert ($newvalue) wird dann anstatt des ursprünglich via attr <name> vorgegeben Wertes gespeichert.
Das ganze hat keinerlei Einfluss auf bestehende AttrFn und dem bisherigen Schema mit nur einer optionalen Fehlermeldung als return Value.
Anwendungsszenarien wären bspw:
- z.B. on-the-fly Verschlüsselung von Passwörtern, damit diese nicht im Klartext in der GUI stehen. Das Passwort wird einmal verschlüsselt und kann so durch das Modul dennoch verwendet werden (Das Modul muss natürlich sicher stellen, das ein verschlüsseltes Passwort nicht nochmal verschlüsselt wird)
- abfangen von gängigen Syntaxfehlern und deren direkte Korrektur (z.B. Anführungszeichen oder fehlende Klammern)
Bsp:
sub xxx_AttrFn(@_)
{
....
# genereller Fehler des Values
return "invalid attribute $val......";
# Value ist generell zwar in Ordnung, muss aber verändert gespeichert werden.
return (undef, $newval);
# value ist in Ordnung (wie gehabt)
return;
}Ich hoffe das ist so in Ordnung.
Viele Grüße
Markus
hallo markus,
in meinen modulen mache ich es so das ich den neuen wert direkt in $attr{$name}{$attrName} eintrage wenn ich den wert aus irgendeinem grund noch verändern muss und gebe dann einen passenden text zurück der dann angezeigt wird.
das ist zwar vielleicht etwas umständlicher hat aber den vorteil der sichtbaren meldung.
das würde mit dieser änderung nicht gehen bzw. wenn ich wie bisher etwas anzeigen möchte muss ich es weiter wie bisher machen.
gruss
andre
Hallo andre,
ich verstehe gerade nicht ganz deinen Usecase. Bisher ist es ja so, dass wenn man in der AttrFn einen Wert prüft, so kann man den zwar durchaus direkt in $attr{$name}{$attrName} schreiben, aber wird dieser Wert nach erfolgreichen Ende der AttrFn eh wieder mit dem originalen Wert überschrieben (siehe fhem.pl):
$a[0] = $sdev;
$ret = CallFn($sdev, "AttrFn", "set", @a);
if($ret) {
push @rets, $ret;
next;
}
my $val = $a[2];
$val = 1 if(!defined($val));
$attr{$sdev}{$attrName} = $val;
Du kannst aber mit dem Patch dennoch eine Meldung ausgeben, wenn der Wert einen Fehler haben sollte usw.
Viele Grüße
Markus
der wert wird eben gerade nicht wieder überschrieben wenn du eine meldung zurück gibst.
if($ret) {
push @rets, $ret;
next; <--- überspringt den rest der schleife
}
gruss
andre
Ja gut, aber meiner Meinung ist eine Meldung wie "attribute [xxx] converted to [yyy]" nicht wirklich eine Fehlermeldung. Und momentan bricht die schleife ja nur ab, wenn man eine Fehlermeldung zurückgibt.
Desweiteren sollten (meiner Meinung nach) Modulfunktionen nicht auf die FHEM internen Datenstrukturen direkt zugreifen. Der Zugriff sollte durch entsprechende Funktionen vorgenommen werden, damit so nicht andere Einträge von anderen Modulen/Definitionen verändert werden können.
Gruß
Markus
es ist eine meldung. von fehler ist nicht die rede.
ich meine ja nur das eine änderung wie du sie vorschlägst auch eine meldung unterstützen sollte.
bei 'meiner' version wird für die geänderten Attribute ja leider auch kein event getriggert.
gruß
andre
Dieses Szenario war nun nicht der primäre Anstoss für diesen Patch ;-)
Ich würde eine solche informative Meldung im Log ausgeben, da überall in FHEM der gefüllte return-Value eine Fehlermeldung bedeutet.
Evtl. hat Rudi dazu eine Idee. Mir fällt da spontan nichts einfaches ein.
Gruß
Markus
bei get (und set) ist der gefüllte return wert eine meldung. nicht unbedingt ein fehler.
das attribut setzen würde ich genau so interaktiv sehen wie get und set und eine meldung nur im log werden die meisten nicht sehen.
aber du hast recht. rudi soll erst mal was dazu sagen.
Zitat von: Markus Bloch am 12 Dezember 2014, 22:53:44
Desweiteren sollten (meiner Meinung nach) Modulfunktionen nicht auf die FHEM internen Datenstrukturen direkt zugreifen. Der Zugriff sollte durch entsprechende Funktionen vorgenommen werden
Das ist nicht in allen Fällen umsetzbar.
Zitat von: betateilchen am 12 Dezember 2014, 23:19:43
Das ist nicht in allen Fällen umsetzbar.
Das ist aktuell auch durchaus so. Daher ja auch Konjunktiv ;-)
ok, ich korrigiere: Es wird auch künftig vermutlich nicht in allen Fällen umsetzbar sein oder werden.
Ich finde es problematisch, wenn ein Programm hinter meinem Ruecken mich korrigiert. Beispiel: ich habe heute eine Weile gebraucht, bis ich kapiert habe, das split(" ", $text) nach \s+ und nicht nach Leerzeichen trennt, ich finde das nicht in Ordnung.
Bei den erwaehnten Szenarien finde ich folgende Loesungen besser:
- Verschluesselung: Das ist kein Attribut, sondern ein set befehl, und das Ergebnis wird in einem Reading gespeichert.
- Syntaxfehler: in dem von AttrFn zurueckgelieferten Fehlermeldung steht, was nach der Ansicht des Moduls richtig waere. Damit lernt der Benutzer, wie man es richtig macht, und wird nicht verwirrt, wenn ein anderes Modul (oder seine Perl-Funktion) damit nicht klarkommt.
Vielleicht gibt es andere Szenarien, wo deine Loesung die Richtige ist, ich sehe diese aber noch nicht.
Nunja ich erklär mal das Szenario wo diese Idee eigentlich herrührt.
Ich möchte im FB_CALLMONITOR eine Funktion integrieren, die es ermöglicht das Telefonbuch remote via Telnet Zugang ausliest. Dazu ist das FritzBox Passwort notwendig, welches FHEM bekannt sein muss.
Da dieses Passwort für mich am besten als Attribut passt, soll das Passwort beim setzen direkt durch die AttrFn unkenntlich gemacht werden:
mysupersecretpassword => [bXlzdXBlcnNlY3JldHBhc3N3b3JkIA==]
Und so in dieser Form auch in der fhem.cfg gespeichert werden. Die AttrFn erkennt dann, dass der Value in eckigen Klammern ist und weis, dass es sich bereits um ein unkenntliches Passwort handelt.
Das Passwort setzen via Set und das Ergebnis als Reading passt nicht, da es sich meiner Meinung nach nicht um Reading/Event handelt, sondern um einen Konfigurationswert.
Daher würde ich das auf diese Weise gerne lösen.
das hinterlegen von passwörtern brauchen inzwischen ein paar module und eine allgemeine lösung wäre glaube ich nicht schlecht.
die frage ist was genau das unkenntlich machen bewirken soll. meiner meinung nach sollte das password ist bei einem list nicht sichtbar und man kann die list ausgabe zum debugger direkt posten und weitergeben
das password irgendwie modul spezifisch zu verschlüsseln ohne ein installations spezifisches master password zu haben bringt nichts. jeder der das gleiche modul hat kann das password entschlüsseln.
wie wäre es an der stelle des password einen beliebigen perl ausdruck zuzulassen. dann kann man z.b. einfach {myPassword()} schreiben und das password steht nur in einem 99_myUtils file und taucht bei einem list nirgends auf. noch nicht mal unsicher verschleiert. wenn jemand hier das password direkt als string hin schreibt ist es halt so.
gruss
andre
Hi,
ich finde den Vorschlag von Markus durchaus schlüssig und den Konventionen von fhem angepasst. In Bezug auf Sicherheit hast Du, Andre, sicher recht. Allerdings ist es doch so: wer ein list absetzen kann kommt auch auf die 99er. Die 99er sind für viele user auch eher eine Schranke. Fort know macht jetzt (mMn) weder die eine noch die andere Variante ;)
vg
jörg
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
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.
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.
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
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.
naja, ich würde mich auch wohler füllen wenn das wenigstens nicht auf dem Silbertablett im attrib steht. ;)
vg
jörg
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)
Zitat von: Markus Bloch am 13 Dezember 2014, 20:27:49
@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 8)
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?
Zitat von: justme1968 am 13 Dezember 2014, 20:32:15
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 ;D
Man müsste sich nur auf ein Verfahren einigen.
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.
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
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.
Ich würde folgende Funktionen für die 99_Utils.pm vorschlagen:
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;
}
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:
{xor_encode("test","mysupersecretkey")} => "44544b10"
{xor_decode("44544b10","mysupersecretkey")} => "test"
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.
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
Zitat von: Markus Bloch am 18 Dezember 2014, 19:02:32
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.
Zitat von: Markus Bloch am 18 Dezember 2014, 19:02:32
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
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.
Zitat von: tupol am 18 Dezember 2014, 19:41:27
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).
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.
Deswegen ja: http://forum.fhem.de/index.php/topic,30528.0.html
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.
Zitat von: rudolfkoenig am 19 Dezember 2014, 11:13:29
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.
Falls du dafuer FileRead/FileWrite verwendest (am besten in einer zentralen Funktion), dann wuerde das auch ohne configDB funktionieren.
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.
Zitat von: rudolfkoenig am 19 Dezember 2014, 11:13:29
- 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 :-)
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.
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.
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);
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);
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);
}
Vielleicht wäre noch eine deletePassword() Sub sinnvoll, damit die Liste nicht mit Leichen vollgepflastert wird.
Soweit wie ich es durchblicke, finde ich es gut. Trennst Du key und password mit "|"? Da wird es Leute geben, die das Zeichen im Passwort oder key benutzen. Besser wäre vielleicht ein \n zum Trennen (also 2-Zeilenweise). Warum nimmst Du eigentlich xor und nicht MD5?
Gruß
tupol
Zitat von: tupol am 28 Dezember 2014, 21:00:23
Soweit wie ich es durchblicke, finde ich es gut. Trennst Du key und password mit "|"? Da wird es Leute geben, die das Zeichen im Passwort oder key benutzen. Besser wäre vielleicht ein \n zum Trennen (also 2-Zeilenweise).
Ja, da hast du wohl recht, nunja irgendwie muss man ja key und password zusammen abspeichern. Das ließe sich aber durchaus noch ändern. Ich wollte es vermeiden mit Data::Dumper eine weitere Modulabhängigkeit ins Spiel zu bringen.
Zitat von: tupol am 28 Dezember 2014, 21:00:23
Warum nimmst Du eigentlich xor und nicht MD5?
Nunja, ganz einfach. MD5 ist eine kryptographische Hashfunktion (bzw. eine Einwegverschlüsselung). Man kann sie nicht mehr entschlüsseln. Da man das Passwort aber unter Umständen in Klartextform braucht (z.B. beim FritzBox telnet Login), muss es wieder in originaler Form zur Verfügung stehen. Natürlich steht es dem Modulentwickler/User frei als Passwort einen MD5 Hash zu hinterlegen. Das macht die Sache natürlich nochmal eine Stufe sicherer. Es gibt aber dennoch Fälle in der das Passwort in originaler Form benötigt wird (z.B. um ein One-Time-Password mit der aktuellen Zeit als Komponente zu bilden).
Hier nochmal ein Update:
Die xor-Funktionen (leicht verbessert, im Falle Digest::MD5 steht nicht zur Verfügung):
######## xor_encode ####################################################
# What : encrypts a given string with XOR encryption
# Call : { xor_encode("foo bar", "key") }
# Returns : "5e585816555447"
sub xor_encode($$)
{
my ($str, $key) = @_;
if(eval "use Digest::MD5;1")
{
$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;
}
######## xor_encode ####################################################
# What : decrypts a given string with XOR encryption
# Call : { xor_decode("5e585816555447", "key") }
# Returns : "foo bar"
sub xor_decode($$)
{
my ($str, $key) = @_;
if(eval "use Digest::MD5;1")
{
$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;
}
Die storePassword() Funktion:
$err = storePassword($index, $password);
sub storePassword($$)
{
my ($key, $pass) = @_;
my $passwdFile = $attr{global}{modpath}."/FHEM/FhemUtils/passwd";
my %passwdList = ();
$key = $key->{NAME} if(ref($key) eq "HASH" and exists($key->{NAME}));
return "empty key given" unless(length($key));
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, 2);
$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);
}
Die queryPassword() Funktion:
($err, $password) = queryPassword($index);
sub queryPassword($)
{
my ($key) = @_;
my $passwdFile = $attr{global}{modpath}."/FHEM/FhemUtils/passwd";
my %passwdList = ();
$key = $key->{NAME} if(ref($key) eq "HASH" and exists($key->{NAME}));
return "empty key given" unless(length($key));
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, 2);
$passwdList{$tmpKey} = $tmpPass;
}
return (undef, $passwdList{$key}) if(exists($passwdList{$key}));
return ("no password stored", undef);
}
Beide Funktionen verwenden FileRead/FileWrite, sollten also (meiner Meinung nach) mit configDb kompatibel sein. Als Trennzeichen wird " <-> " verwendet (was eigentlich nicht wirklich in Passwörtern vorkommt), ob das das optimale ist, lässt sich sicher drüber diskutieren. Da die FileRead/FileWrite Funktionen zeilenbasiert die Datei lesen/schreiben möchte ich Index und Passwort auch gerne auf einer Zeile belassen, da es sich so einfacher pro Zeile verschlüsseln lässt und anschließend es auch einfacher ist das ganze zeilenweise einzulesen und zu verarbeiten. Man kann als Index auch $hash übergeben (sofern $hash->{NAME} existiert), dann wird $hash->{NAME} als Index verwendet.
Nachwievor gilt als Vorraussetzung: http://forum.fhem.de/index.php/topic,30528.0.html
Eure Meinung?
Viele Grüße
Markus
hallo markus,
ich mag die version. habe aber einen vorschlag:
wie wäre es das file nicht zeilenweise bzw. mit separator zu schreiben sondern einen 'echten' hash mit Data::Dumper zu serialisieren und mit eval wieder einzulesen?
das ist bei der zu erwartenden anzahl an einträgen auch resourcen technisch noch lange kein problem und spart alle klimmzüge irgendwelche zeichen zu vermeiden oder zu maskieren.
ich mache das in LightScene und es funktioniert sehr gut.
gruß
andre
Prinzipiell ja, ich wollte allerdings Modulabhängigkeiten vermeiden.
Data::Dumper ist ein core modul und sollte immer vorhanden sein. sogar auf der fritzbox. im gegensatz zu JSON das ich sonst vorgeschlagen hätte.
kreative (gute) Idee.
Siehe http://forum.fhem.de/index.php?topic=30528
Fuer die Verwendung von xor habe ich noch keine Begruendung gesehen, und selbst kommt ich auf keine sinnvolle.
Zitat von: rudolfkoenig am 29 Dezember 2014, 09:56:28
Fuer die Verwendung von xor habe ich noch keine Begruendung gesehen, und selbst kommt ich auf keine sinnvolle.
Nunja, es war als weiter Sicherheitsstufe gedacht, damit Passwörter nicht so ohne weiteres im Klartext gespeichert werden (zumindest in den Fällen, in denen das nötig ist). Bei der FritzBox brauche ich das Passwort im Klartext und ich wollte es ungern in Klartextform in einer Datei speichern, wo man es einfach rauslesen kann.
Ich teile deine Argumentation nicht, da ich die Anwender nicht in falscher Sicherheit wiegen will. Lieber sieht der Benutzer direkt, dass da Passwoerter sind, und schuetzt die Daten. Ich will dich nicht davon abhalten, selbst auf xor zu setzen, ich will das aber nicht als "offiziell gewuenscht" propagieren.
Mir wäre die Verschlüsselung ganz recht. Zwar ist sie leicht knackbar aber nur mit Insiderwissen. Außerdem ist fhem bei mir über samba zugänglich und irgendwann kommen auch die Kinder drauf, dort mal nach dem Passwort für die Fritzbox zu forschen. (Kindersicherung :) Durch die Verschlüsselung habe ich wieder ein paar Monate Vorsprung :-)
Mein Plan wäre es, das Passwort auch verschlüsselt abzulegen. Sofern es keine einheitliche Methode dafür in FHEM gibt, würde ich die xor-Funktionen modulspezifisch in FB_CALLMONITOR einbauen.
Wie gerade per PN geschrieben:
GANZ WICHTIG. Der Device-Name (Nicht der Modulname) ;) muss ein dritter Parameter in der Funktion sein. Dann kann kein Entwickler versehentlich die Passwörter anderer Module ändern, weil er den selben Key benutzt und sich nicht richtig eingelesen hat. Das sollte nicht über den key allein passieren sondern über einen weiteren Parameter.
das ist nicht wirklich eine gute idee. dann funktioniert rename nicht mehr.
wir reden nicht von einem hoch sicherheits system. wenn du anderen modulen nicht traust hash du ein ganz anderes problem.
Hm... Leider. Etwas Isolation der Module wäre schön nicht schlecht. Mit der Verbreitung steigt auch Gefahr, dass jemand auf diesem Wege, also durch Manipulation eines Moduls, in das System einbricht. Ist aber wirklich ein anderes Thema.
ja. dafür bräuchte man etwas in richtung des sanbox vorschlags . aber das ist wirklich ein ganz anderes thema.
Zitat von: justme1968 am 29 Dezember 2014, 20:01:27
das ist nicht wirklich eine gute idee. dann funktioniert rename nicht mehr.
wir reden nicht von einem hoch sicherheits system. wenn du anderen modulen nicht traust hash du ein ganz anderes problem.
Das hat nichts mit trauen zu tun sondern mit vorhersehbaren Fehlern. Ich melde mich auch gerne als typischer Kandidat. ;)
Module (z.B. FRITZBOX) werden zudem auch mehrfach verwendet und brauchen jedes ein eigenes Login. Zudem wäre es damit auch möglich, die Passwortdatei zu komprimieren, indem alle Passwörter entfernt werden, deren Device-Namen nicht mehr vorhanden sind. "Rename" muss natürlich im Modul berücksichtigt werden, aber dafür gibt es ja schon eine Funktion. Die könnte man dann auch gleich durch eine Rename-Funktion in dem Framework unterstützen.
ob die beziehung zwischen modul und password 1:n, n:1 oder n:m ist hängt aber vom modul selber ab. hier was vorzuschreiben ist unter umständen falsch. oder man sollte gleich konsequent sein und $hash verwenden und es im rename und delete (und copy?) gleich mit berücksichtigen.
es kommt halt immer mehr dazu und aus einer einfachen möglichkeit ein password zu verschleiern/verbergen wird etwas das so kompliziert ist das es nicht mehr umgesetzt wird.
Ich finde das nicht kompliziert sondern nur konsequent im Sinn des modularen Aufbaus von FHEM. Hier jetzt von diesem Modul-Konzept abzuweichen, finde ich nicht gut. Man sollte die Möglichkeit von crossover-Fehlern so gering wie nur möglich halten. Letztendlich handelt es sich hier nur um Attributwerte, die "geschützt" ausgelagert werden und nicht mehr in der cfg stehen.