Hallo,
ich habe das Modul nach der Wiki Anleitung erfolgreich in Betrieb genommen und für einen Webzugang ein allowed device gesetzt.
List des Webzugangs:
Internals:
BYTES_READ 20405
BYTES_WRITTEN 143160
CONNECTS 9
CSRFTOKEN csrf_280080103165842
DEF 8086 global
FD 7
FUUID 5c655c08-f33f-21e6-abd6-c13b84a6fdde520f
NAME WEBMeli
NR 54
NTFY_ORDER 50-WEBMeli
PORT 8086
SSL 1
STATE Initialized
TYPE FHEMWEB
READINGS:
2021-01-24 15:08:50 state Initialized
Attributes:
HTTPS 1
closeConn 0
column Drucker:Benutzer Weihnachten:Benutzer Residents:Position,Bewohner,Gäste,Teufelspfad_14 Security:Benutzer Küche:Benutzer Gaestezimmer:Benutzer Buero:Benutzer Schlafzimmer:Benutzer Garten:Benutzer Bad:Benutzer Esszimmer:Benutzer Flure:Benutzer Gaestebad:Benutzer Gaestetoilette:Benutzer Keller:Benutzer Küche:Benutzer Wohnzimmer:Benutzer SOS:Benutzer
confirmJSError 0
hiddengroup pushButton,CUL_HM,remote
hiddenroom Spritpreise-Benzin,CCU,EnOcean,Energiemessung,Logik,Spritpreise,Everything,Unsorted,SD_WS_Maverick,SOMFY,CUL_TCM97001,HUEDevice,Heizung,IT,LogFiles,Plots,Server,System,Timer,CUL_HM,Logfile,Commandref,Remote doc,Edit files,Select style,Event monitor,input,Save,Detail,details,Definition
iconPath fhemSVG:openautomation:default
sslVersion TLSv12:!SSLv3
stylesheetPrefix dark
List des allowed device:
Internals:
FUUID 600d5f88-f33f-21e6-600c-22c577dd941dde44
NAME allowed_WEBMeli
NR 8287
STATE validFor:WEBMeli
TYPE allowed
READINGS:
2021-01-24 15:15:13 lastAuthExpires 1611584113
2021-01-24 15:15:13 lastAuthExpiresFmt Mon, 25 Jan 2021 14:15:13 GMT
2021-01-24 15:15:13 lastAuthUser xxx
2021-01-24 15:10:03 state validFor:WEBMeli
Attributes:
basicAuth { "$user" eq "xxx" && gAuth("GoogleAuth","$password") == 1 }
basicAuthExpiry 1
basicAuthMsg Das Passwort ist per Authy einzugeben
validFor WEBMeli
Das Anmelden funktioniert auch prima und - obwohl ich basicAuthExpiry auf einen Tag gesetzt habe - muss ich mich nach kürzester Zeit wieder authorisieren. Damit ist leider mein WAF Faktor auf Null gesunken.
Habe ich etwas übersehen?
Danke und Gruß
Wolfgang
basicAuthExpiry wird über ein cookie gesteuert.
Wenn Dein Browser das cookie nicht speichert, wäre das Verhalten nachvollziehbar.
Tipp 1: Du solltest den Titel des Threads so ändern, dass es einen Bezug zu "allowed" gibt, denn DORT ist ggf. die Problemursache zu suchen, nicht im Google Authenticator.
Tipp 2: Nach dem Ändern des Titels solltest Du den Thread in das für "allowed" richtige Unterforum verschieben.
Hallo betateilchen,
ich habe es mit diversen Browsern geprüft, Handy und auf dem Mac. Aber überall habe ich das gleiche Verhalten. Gefühlt nach einer Minute erscheint wieder das Anmeldefenster.
Was kann ich noch tun?
Danke und Gruß
Wolfgang
Zitat von: FHEM_Starter am 25 Januar 2021, 18:34:28
Was kann ich noch tun?
Warten, bis Rudi den Thread entdeckt und sich meldet.
Na toll. Und ich habe gehofft, dass ich fein raus bin, weil ich nichts mit gAuth zu tun habe.
@FHEM_Starter: kannst Du bitte
- "attr WEBMeli verbose 5" setzen
- danach anmelden mit Authentifizierung
- dann eine Minute warten (bzw. so lange, bis das Problem kommt)
- und wieder versuchen die Seite aufzurufen
- das FHEM-Log hier komprimiert anhaengen (siehe erweitere Optionen).
Wie betateilchen geschrieben hat, wird ein Cookie erwartet, ich vermute auch, dass das Cookie nach einer Minute nicht mehr gesendet wird. Das Log von oben dient nur der Nachweis. Wenn die Theorie stimmt, dann kann ich leider nichts wirklich tun, man muss rausfinden, wer das Cookie loescht, trotzt Anweisung, dass es 1 Tag lang gueltig ist. Wenn ich mich irren sollte, und das Cookie doch geliefert wird, dann werde ich das Problem natuerlich beheben.
Apropos: die gleichen Symptome wurde man haben, wenn die Uhren von Server und Client sehr stark voneinander abweichen. Kannst Du das bitte pruefen?
Zitat von: rudolfkoenig am 25 Januar 2021, 21:39:16
Na toll. Und ich habe gehofft, dass ich fein raus bin, weil ich nichts mit gAuth zu tun habe.
:D :D :D
Zitat von: rudolfkoenig am 25 Januar 2021, 21:39:16
man muss rausfinden, wer das Cookie loescht, trotzt Anweisung, dass es 1 Tag lang gueltig ist.
Geraten: Vielleicht ein Browserfenster bzw. -tab im privaten Modus, das zwischendurch geschlossen wird und dabei das Cookie beseitigt?
Hallo Rudi,
danke dass Du Dich dieses Problems annimmst. Anbei das LogFile. Sollte noch irgendwas fehlen, bitte kurze Nachricht.
Die Uhrzeit sowohl vom FHEM Server (NUC) als auch von meinem MAC laufen zeitgenau, keine Abweichungen.
@Udo: Zwischem dem Anmelden an WebMeli und dem Auftreten des "Fehlers" habe ich zwischendurch keine Fenster geschlossen.
Danke und Gruß
Wolfgang
Zitat von: FHEM_Starter am 26 Januar 2021, 13:40:43
Die Uhrzeit sowohl vom FHEM Server (NUC) als auch von meinem MAC laufen zeitgenau, keine Abweichungen.
Hi,
ist auch jeweils die gleiche Zeitzone eingestellt?
Falls nicht laufen die beiden eben nicht zeitgenau. ;-)
Oder eine Privacy App, die Cookies löscht ....
Hallo Frank,
auf dem Intel NUC liefert date: Di 26. Jan 14:26:47 CET 2021
Auf meinem MAC: Di 26 Jan 2021 14:26:48 CET
@Wernieman
Zitat
Oder eine Privacy App, die Cookies löscht ....
nicht dass ich wüsste. Aber danke für den Hinweis.
Gruß Wolfgang
Kannst Du mal dein freezemon device löschen und dann nochmal testen?
Alternativ auch das echodevice.
Da passiert irgendwas merkwürdiges:
Cookie: AuthToken=bWplOjk0MTU3MQ==
2021.01.26 13:09:45 4: WEBMeli_192.168.17.27_52624 GET /fhem?XHR=1&inform=type=status;filter=;since=1611662984;fmt=JSON&fw_id=17598×tamp=1611662985436; BUFLEN:0
...
2021.01.26 13:11:57 4: Connection closed for WEBMeli_192.168.17.27_52624: EOF
2021.01.26 13:11:57 4: Connection accepted from WEBMeli_192.168.17.27_52644
...
2021.01.26 13:11:57 3: Login denied for user >mje< via WEBMeli_192.168.17.27_52644
Nachdem die Verbindung geschlossen und direkt danach eine neue Verbindung aufgebaut wurde, ist das Cookie nicht mehr gültig. Klingt vom Verhalten her logisch.
Hallo Udo,
FreezeMon habe ich gelöscht. Verbose 5 auf WebMeli, in neuem Fenster angemeldet, 1 Minute gewartet, versucht auf einen anderen Raum zu klicken, erneutes Anmelden notwendig. Anmeldung durchgeführt.
LogFile anbei.
Danke für Deine Recherche
Gruß Wolfgang
hast du mal hardware ohne "angebissenen apfel" probiert?
basicAuthExpiry hinterlegt das aktuelle basicAuth (falls Vorhanden: name:passwort, base64 kodiert) in ein Cookie mit X Tagen Ablauf.
Falls basicAuth nicht gesetzt ist (und nur dann), wird dieses Cookie rausgeholt, und statt basicAuth verwendet.
gAuth ist ein 6-stelliger Pseudo-Zufallszahl, was sich alle 30 Sekunden aendert, und eine Minute lang gueltig ist.
Allowed prueft ein Passwort nur einmal fuer jede TCP-Verbindung.
FHEMWEB schliesst inaktive Browser-Verbindungen nach eine Minute.
Selbst ohne basicAuthExpiry duerfte eine mit gAuth verifizierte Verbindung nach eine Minute Inaktivitat nach Passwort fragen.
basicAuthExpiry im Zusammenhang mit gAuth ist komplett sinnlos, jedenfalls so wie es z.Zt. implementiert ist.
Nachtrag: die Kombination beider Attribute kommt mir aus "fachlicher" Sicht sinnlos vor: gAuth will die Sicherheit erhoehen durch staendig aendernde Werte, basicAuthExpiry macht genau das Gegenteil: speichert das Passwort noch laenger, als was der Browser fuer sinnvoll haelt.
Zitathast du mal hardware ohne "angebissenen apfel" probiert?
Hallo Frank,
auch auf "Bill Gates"-Rechnern kein Erfolg ;)
Gruß Wolfgang
Zitat von: rudolfkoenig am 26 Januar 2021, 16:01:14
basicAuthExpiry im Zusammenhang mit gAuth ist komplett sinnlos, jedenfalls so wie es z.Zt. implementiert ist.
Und das bedeutet nun was?
An welcher Stelle müsste etwas geändert werden?
- Konfiguration des allowed devices?
- allowed.pm?
- GoogleAuthenticator.pm?
Zitat von: rudolfkoenig am 26 Januar 2021, 16:01:14
Selbst ohne basicAuthExpiry duerfte eine mit gAuth verifizierte Verbindung nach eine Minute Inaktivitat nach Passwort fragen.
Nicht nach einer Minute, sondern offenbar immer zur übernächsten halben Minute nach erfolgreicher Anmeldung (xx:xx:00 bzw. xx:xx:30).
Die Implementierung der Anmeldung mit gAuth() sollte keine Hochsicherheitslösung für die Anmeldung an FHEM werden, sondern einfach ein festgeschriebenes Passwort ersetzen.
Deshalb steht dieses Beispiel als Anwendungsfall in der commandref. ( ich benutze gAuth() für das Prüfen von per email an FHEM verschickter Befehle, dafür braucht es keine Cookies :) )
Bietet das allowed-device die Möglichkeit, sich eine erfolgreiche Authentifizierung intern zu merken?
Dann könnte man vielleicht sowas wie
attr <allowedDevice> basicAuth { authenticated() || gAuth("gAuth","$password") ==1 } verwenden.
ZitatAn welcher Stelle müsste etwas geändert werden?
Wenn man trotz meines Nachtrag (s.o.) darauf besteht, dann muessten alle "genehmigten" gAuth-Zahlen abgespeichert werden, und bis X Tage (siehe basicAuthExpiry) als gueltig akzeptiert werden. Das ist mAn gAuth spezifisches, deswegen sehe ich das in GoogleAuthenticator.pm.
ZitatBietet das allowed-device die Möglichkeit, sich eine erfolgreiche Authentifizierung intern zu merken?
Ja, aber das ist an die TCP-Verbindung gebunden.
allowed kann nicht ohne Weiteres fuer eine neue Verbindung sagen, ob es ok ist oder nicht.
Zitat von: rudolfkoenig am 26 Januar 2021, 16:37:42
Wenn man trotz meines Nachtrag (s.o.) darauf besteht, dann muessten alle "genehmigten" gAuth-Zahlen abgespeichert werden, und bis X Tage (siehe basicAuthExpiry) als gueltig akzeptiert werden. Das ist mAn gAuth spezifisches, deswegen sehe ich das in GoogleAuthenticator.pm.
Ok, ich denke mal drüber nach. Vermutlich würde ich dann aber die Gültigkeit innerhalb von gAuth() auf einen Tag begrenzen.
Eine Anmeldung pro Tag und User halte ich durchaus für zumutbar.
Hallo Rudi, hallo Udo,
zunächst einmal vielen Dank für Eure Unterstützung und Eure Hilfe.
Ich persönlich könnte mit einer Anmeldung pro User/Tag auch prima leben.
Gestattet mir eine Frage zu diesem Thema: Ist es denn prinzipiell möglich, statt den 6-stelligen Code einzugeben, die Authorisierung auch über eine Push-Notification zu erreichen? Bei Anwendungen wie Lastpass und einige andere habe ich diese Funktion und es ist einfach super komfortabel mit nur einem Klick den Zugang zu autorisieren (WAF-Faktor > 100%).
Danke und Gruß
Wolfgang
Prinzipiell ist vieles moeglich, sowas ist aber mW nicht implementiert.
Abgesehen davon, dass ich das Konzept nicht wirklich verstanden habe :)
ZitatAbgesehen davon, dass ich das Konzept nicht wirklich verstanden habe
.. in diesem Punkt sind wir schon zu zweit ;D
Wo müsste so ein Ansatz denn implementiert sein?
Zitat von: FHEM_Starter am 26 Januar 2021, 17:00:22
Ist es denn prinzipiell möglich, statt den 6-stelligen Code einzugeben, die Authorisierung auch über eine Push-Notification zu erreichen?
Das hat jetzt aber nix mehr mit GoogleAuthenticator zu tun.
Zitat von: betateilchen am 26 Januar 2021, 17:25:18
Das hat jetzt aber nix mehr mit GoogleAuthenticator zu tun.
An welcher Stelle MÜSSTE denn angesetzt werden, um eine solche Funktion zu realisieren?
Vermutlich muesste das allowed Modul lernen mit dem push Modul zu reden, oder andersherum.
Wenn ich wuesste, was du vorhast, dann koennte ich vmtl. was Genaueres sagen.
Und nein, das ist keine Zusage, dass ich sowas bauen will.
@FHEM_Starter: Teste mal bitte die angehängte Modulversion 98_GoogleAuth.pm
Dazu musst Du Deine Abfrage im allowed_device um den eigenen Namen des device ergänzen:
gAuth("GoogleAuth","$password","allowed_WEBMeli")
Nach diesen Änderungen sollte die Abfrage erst nach 5 Minuten erneut erscheinen.
Die 5 Minuten sind nur für Testzwecke. Wenn das funktioniert, werde ich die Gültigkeit noch ändern.
Hallo Udo,
Datei heruntergeladen, reload gemacht, gAuth angepasst und siehe da: alles klappt. Erst nach 5 Minuten erneute Anmeldung notwendig. Du kannst den Timer nun anpassen.
;) ;) ;)
Vielen Dank für den Support.
Wolfgang
Danke für die Rückmeldung.
Zitat von: rudolfkoenig am 26 Januar 2021, 18:40:32
Vermutlich muesste das allowed Modul lernen mit dem push Modul zu reden, oder andersherum.
Wenn ich wuesste, was du vorhast, dann koennte ich vmtl. was Genaueres sagen.
Und nein, das ist keine Zusage, dass ich sowas bauen will.
Hallo Rudi,
ich kann es sicherlich nicht von der technischen Seite beschreiben, jedoch aus Sicht des Anwenders:
Heute habe ich die Möglichkeit, den Zugriff auf eine FHEM Webseite entweder via einem hardcoded Passwort oder nun auch via GoogleAuth abzusichern. Letzteres ist eine feine Sache, erhöht es doch die Sicherheit.
Was jetzt noch die Sahne auf der Haube wäre, ist folgender Ablauf:
- Ich will eine Webseite meiner FHEM Instanz aufrufen
- bevor der Zugriff gewährt wird, erhalte ich eine Push Notification auf mein Handy (siehe Bild 1)
- diese Anfrage muss ich genehmigen/ablehnen (siehe Bild 2)
- nach dem Genehmigen muss ich Authorisierungs App per Fingerabdruck (je nach Einstellungen auf dem iPhone) öffnen (siehe Bild 3) und
- der 6-stellige Code wird an die aufrufende Instanz zurück gesendet (zumindestens ist das meine Vermutung)
Es wäre schön, wenn Du mir ein Feedback gibst.
Danke und Gruß
Wolfgang
Kannst Du dazu bitte einen neuen Thread im richtigen Unterforum für "allowed.pm" aufmachen?
Es macht wenig Sinn, hier im Thread noch mehr Dinge durcheinander zu behandeln.
Die Änderung an GoogleAuth.pm kommt voraussichtlich morgen per Update.
ZitatEs wäre schön, wenn Du mir ein Feedback gibst.
Vermutlich laesst sich sowas jetzt schon irgendwie basteln:
- da die Login-Pruefung nicht warten kann, geht der erste Versuch schief, der Browser zeigt wieder die Anmeldemaske
- allowed generiert ein Event (siehe reportAuthAttempts)
- ein notify sendet eine Push-Notifikation
- der Mobiltelefon-Nutzer sendet eine Push-Antwort
- auf die Push-Antwort reagiert in FHEM ein notify, und setzt irgendwelche interne Variablen
- der naechste Browser-Zugriff wird per Perl-Ausdruck wg. der Variablen genehmigt (analog zu gAuth).
Das ist nur ein grober Fahrplan, um zu zeigen wie es in FHEM jetzt schon mit etwas an "Endbenutzer"-Programmierung machbar ist.
Damit es anfaengerfreundlich wird, muesste man allowed erweitern oder ein neues Modul fuer diesen Zweck erstellen.
Aufwendiger ist die Mobiltelefon-Seite: mir ist nicht bekannt, dass ein API fuer "ja/nein" Popups wg Push-Nachrichten gibt.
Wenn nicht, muss man eine App dafuer bauen, und dafuer sorgen, dass es installierbar ist.
Man kann auch die basicAuth-Masken vermeiden, dann wird es aufwendiger :)
Bevor jemand falsche Hoffnungen hat: ich habe nicht vor, die erwaehnten Erweiterungen zu realisieren.
Viel einfacher: FHEM erst gar nicht extern erreichbar machen ;)
Für den Aufwand würde ein eigener Proxy, der das auth erledigt, wahrscheinlich besser sein.