Google Authenticator und allowed device ==> FHEM login issue

[FHEM_Starter]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[betateilchen]

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.

[FHEM_Starter]

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

[betateilchen]

Was kann ich noch tun?

Warten, bis Rudi den Thread entdeckt und sich meldet.

[rudolfkoenig]

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?

[betateilchen]

Na toll. Und ich habe gehofft, dass ich fein raus bin, weil ich nichts mit gAuth zu tun habe.

[betateilchen]

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?

[FHEM_Starter]

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

[Frank_Huber]

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.

[Wernieman]

Oder eine Privacy App, die Cookies löscht ....

[FHEM_Starter]

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

Oder eine Privacy App, die Cookies löscht ....

nicht dass ich wüsste. Aber danke für den Hinweis.

Gruß Wolfgang

[betateilchen]

Kannst Du mal dein freezemon device löschen und dann nochmal testen?
Alternativ auch das echodevice.

Da passiert irgendwas merkwürdiges:

Code Auswählen Erweitern


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&timestamp=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.

[FHEM_Starter]

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

[frank]

hast du mal hardware ohne "angebissenen apfel" probiert?

[rudolfkoenig]

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.