Modularisierung der Authorisierung/Authentifizierung

[Markus Bloch]

Ich würde es besser finden wenn man Basic-Authentifizierung gegen Digest-Authentifizierung tauschen würde. Finde ich sicherheitstechnisch nicht wirklich prickelnd das Passwort im Klartext zu übertragen.

Viele Grüße

Markus

[rudolfkoenig]

sinnvoll log meldungen einzubauen

Habs gemacht. Es muss ja schliesslich einen Grund geben, auf schnelleren Hardware zu wechseln
Um es zu aktivieren muss verbose >= 4 fuer das Eingangsgeraet (telnetPort/WEB) gesetzt werden, global verbose wird nicht konsultiert.

Könnte man den .httpauthheader auch in anderen Fällen mitsenden

Habs eingebaut.

Finde ich sicherheitstechnisch nicht wirklich prickelnd das Passwort im Klartext zu übertragen.

Sinnvollerweise wird basicAuth nur in Verbindung mit HTTPS verwendet. Uebrigens habe ich mir die Muehe mit dieser Modularisierung deswegen gemacht, damit Andere sich auch verwirklichen koennen, also nur zu.

[viegener]

Der Cookie wird ja gesetzt wenn die Anmeldung erfolgreich war und der normale Inhalt (für den ersten Request) zurückgeht.
Könnte man den .httpauthheader auch in anderen Fällen mitsenden (sozusagen ein .httpauthtokenheader)
Alternative: Ein zusätzlicher .httpServerHeader, der auch von anderen Erweiterungen (nicht nur Auth gesetzt werden könnte)?

So jetzt habe ich den Patch neu erstellt und mit Firefox und Chrome getestet.
Allerdings ist doch eine Änderung in FHEMWeb erforderlich, da der Header auch bei erfolgreicher Authentifizierung (also beim ersten Request) mit gesendet wurde. Ich habe das Mitsenden in anderen Fällen dafür wieder auskommentiert, da der Header nur einmal mitgesendet werden muss (für meinen Fall). Deshalb wird der auch nach dem ersten Senden zurückgesetzt.
=> Das ist aber auch im Patch enthalten.

Es gibt an allowed ein Attribut basicAuthExpiry, dass es ermöglicht die basic Authentication nur einmal alle n Tage abzufragen. Dazu muss das Attribut auf den Wert n gesetzt werden. Die Beschreibung ist auch in der allowed-Doku enthalten.

Hoffe das passt jetzt?

[rudolfkoenig]

Hoffe das passt jetzt?

Nicht wirklich:
- Der Patch ist nicht auf 80 Zeichen formatiert
- fuer Datumsformatierung haben wir schon eine Funktion: FmtDateTimeRFC1123
- Die Authenticate-Erweiterung wurde nicht nur fuer diese Cookie-Implementierung gebaut, deswegen moechte ich den AuthHeader immer drin haben.
- mir passt nicht, dass basicAuth (und damit Benutzername/Passwort) als Cookie im Browser gespeichert werden, wo das jeder mit Zugriff zum Browser abschreiben, und in dem eigenen Browser mit einem laengerem Expiry einbauen kann. Wenn basicAuth folgenden Syntax hat:

Code Auswählen Erweitern

{ CheckLDAP($user, $password) }
dann ist das nach einmaligen Abhoeren selbst nach Passwortaenderung anwendbar.
Wenn die Kommunikation nicht abhoerbar ist, dann stellt sich die Frage nach dem Sinn von einem Passwort.

Die ersten drei Punkte koennte ich selbst fixen, beim Letzten faellt mir nichts ein, was nicht Schlangenoel waere.

Vorschlag:
  attr basicAuthCookie days CookieText
Als Cookie wird statt basicAuth CookieText gesetzt, und der Benutzer wird in der Doku darauf hingewiesen, dass diese Methode nur "Schlangenoel" ist, da es nach Abhoeren von einem Hacker beliebig lange angewendet werden kann. Ich wollte das nicht direkt einbauen, da ich unsicher bin, ob es damit fuer dich noch relevant ist.

[viegener]

Nicht wirklich:
- Der Patch ist nicht auf 80 Zeichen formatiert
- fuer Datumsformatierung haben wir schon eine Funktion: FmtDateTimeRFC1123
- Die Authenticate-Erweiterung wurde nicht nur fuer diese Cookie-Implementierung gebaut, deswegen moechte ich den AuthHeader immer drin haben.
- mir passt nicht, dass basicAuth (und damit Benutzername/Passwort) als Cookie im Browser gespeichert werden, wo das jeder mit Zugriff zum Browser abschreiben, und in dem eigenen Browser mit einem laengerem Expiry einbauen kann. Wenn basicAuth folgenden Syntax hat:

Code Auswählen Erweitern

{ CheckLDAP($user, $password) }
dann ist das nach einmaligen Abhoeren selbst nach Passwortaenderung anwendbar.
Wenn die Kommunikation nicht abhoerbar ist, dann stellt sich die Frage nach dem Sinn von einem Passwort.

Die ersten drei Punkte koennte ich selbst fixen, beim Letzten faellt mir nichts ein, was nicht Schlangenoel waere.

Vorschlag:
  attr basicAuthCookie days CookieText
Als Cookie wird statt basicAuth CookieText gesetzt, und der Benutzer wird in der Doku darauf hingewiesen, dass diese Methode nur "Schlangenoel" ist, da es nach Abhoeren von einem Hacker beliebig lange angewendet werden kann. Ich wollte das nicht direkt einbauen, da ich unsicher bin, ob es damit fuer dich noch relevant ist.

Ok, bevor ich den dritten Patch mache, sollten wir besser ein Design abstimmen


- Auf 80Zeichen begrenzen kann ich schon machen
- Die vorhandene Routine nehmen auch (die RFC-Nummern verwechselt deshalb habe ich die Routine nicht gefunden)
- Das mit dem Authenticate-Header immer ist kein grosses Problem, wobei es schön wäre irgendwie zu steuern, dass er nur einmal gesendet werden muss.

Zu Deinen Bedenken, das verstehe ich auch wenn ich nur einen basicAuth-Attribut mit statischem String kannte.
Ich sehe 2 Vorschläge:

a) Statt den Inhalt des Attributes basicAuth zu senden, könnte man ja auch den http-header senden, der ja sowieso bei jeder basicAuth-Anmeldung heute schon mitgeschickt wird nehmen?

b) Alternativ und etwas aufwändiger, wäre es eine Liste der Anmeldungen im allowed-Modul zu verwalten (mit Ablaufdatum) und dann im Cookie nur einen hash oder eine uuid zu versenden. Problem: relativ aufwändig (wg. Verwaltung für abgelaufene Sessions/Cookies) und eigentlich auch nicht wirklich sicherer, da ja immer noch ein basicAuth mit user/password übers Netz geht.

Ich würde vorschlagen Alternative a zu machen



-

[Markus Bloch]

Hallo zusammen,

mit der neuen allowed-Implementierung habe ich hier erste Meldungen, dass damit Blocking-Calls nicht mehr funktionieren:

http://forum.fhem.de/index.php/topic,46498.msg383056.html#new
http://forum.fhem.de/index.php/topic,46256.msg383070.html#new
http://forum.fhem.de/index.php/topic,46515.0.html

Ich nehme mal an, dass dies daran liegt, dass in Blocking das allowed-Modul System nicht nachgezogen ist um eine telnet-Verbindung zu ermitteln.

Kann sich das mal jemand anschauen, da ich bei allowed noch nicht so ganz durchsteige.

Vielen Dank

Gruß
Markus

[Markus Bloch]

Nach dem löschen von "allowed"-Definitionen, funktioniert es wieder: http://forum.fhem.de/index.php/topic,46498.msg383093.html#msg383093

[rudolfkoenig]

@Markus: habs gefixt, getestet und eingecheckt.

[Markus Bloch]

Funktioniert, vielen Dank.

[rudolfkoenig]

@Johannes: bin mit deinem Vorschlag a) einverstanden. b) entspricht einem Session-key Verwaltung, das waere fuer mich im Moment auch zu viel.

[viegener]

@Rudi: Schön, Patch ist anbei (mit Doku in allowed)
(wie oben vereinbart auch mit 80Z / FmtDateTimeRFC1123 etc)
In FHEMWeb ist nur der Teil enthalten um nach erfolgreichern Authenthifizierung den header zurückzugeben.

[rudolfkoenig]

Habs ohne Aenderung eingecheckt.

[viegener]

Habs ohne Aenderung eingecheckt.

Na das gibt mir doch gleich ein gutes Gefühl für den verbleibenden Sonntag 

[rudolfkoenig]

Wg. dem hier: http://forum.fhem.de/index.php/topic,46498.msg385840.html#msg385840 beschriebenen Problems moechte ich das Default beim nicht gesetzten validFor von "all" auf "none" setzen. Wenn jemand bessere Vorschlaege hat, bitte melden.

[Markus Bloch]

Wow Danke. Ich wollte gerade nachfragen, aber du warst schneller.

Gruß
Markus