"Eingeloggt bleiben" im Login Screen wieder implementieren

  • App
    WoltLab Suite Core

    Ich habe mein Live-System gestern auf das WSC 5.4 aktualisiert. Passend dazu habe ich ein Thema erstellt, indem ich auf die neuen Funktionsbeschreibungen hier verlinkt habe und in welchem meine Mitglieder Fehler / Ungereimtheiten melden sollen.

    Heute meldete sich ein Benutzer, der mir mitteilte, dass die Option "Eingeloggt bleiben" im Login Screen verschwunden ist und er dies somit nicht mehr deaktivieren kann. Dies bedeutet, dass er nun immer eingeloggt bleibt, wenn er das Forum verlässt.

    Mir selbst war das nicht aufgefallen, da ich immer eingeloggt bleibe. Es scheint aber tatsächlich Benutzer zu geben, die eben nicht immer eingeloggt bleiben und nach Beenden der Browser-Session ausgeloggt werden wollen.

    Natürlich habe ich ihn darauf hingewiesen, dass er sich vor dem Schließen des Browsers manuell abmelden solle. Dies empfindet er jedoch als Mehraufwand und unpraktisch, womit er prinzipiell recht hat.

    Warum gibt es die Möglichkeit nicht mehr, nur für diese Session eingeloggt zu bleiben? Falls es ein gewolltes Verhalten ist, möchte ich hiermit den Wunsch aussprechen, eine solche Möglichkeit doch bitte wieder zu schaffen.

  • beim Aktivieren dieser Option wurde die Benutzer-ID und ein Hash des Passworts für eine gewisse Zeit als Cookie gesetzt. Dies erlaubte es, den Benutzer automatisch beim Aufruf der Seite anzumelden, wenn die Session bereits abgelaufen war. Das ist aber nicht nur ineffizient (Cookies werden bei jeder Anfrage mitgeschickt), sondern auch unschön, weil so die Prüfsumme des Passwort permanent an den Server geschickt wird.

    Aha. Und das wolltet ihr uns wann mitteilen? Heißt unsere Datenschutzerklärung ist unzutreffend: „Wenn du im Anmeldefenster die Option „Dauerhaft angemeldet bleiben“ auswählst, werden deine Zugangsdaten in verschlüsselter Form als Cookie gespeichert und du musst dich nicht mehr bei jedem Besuch erneut anmelden. Beim ersten Aufruf unserer Seite wird eine neue Sitzung gestartet, diese wird durch ein eindeutiges Cookie deinem Computer zugeordnet, um dich während deines Besuchs wiederzuerkennen. Dieses temporäre Cookie wird beim Beenden deines Browsers gelöscht.“

    Ab der WoltLab Suite 5.4 wird die Session-ID als kryptographisch signierter String als Cookie gespeichert, dies macht die Fälschung des Cookies unmöglich. Gleichzeitig werden Sessions von angemeldeten Benutzern für zwei Wochen auf dem Server vorgehalten, d.h. solange man innerhalb von maximal 14 Tagen die Seite erneut aufruft, ist die gespeicherte Session-ID gültig und die Gültigkeit der Session wird erneut auf 14 Tage gesetzt (sie kann sich damit unendlich verlängern).

    Argh! Solche nicht zwingend notwendigen Cookies sind grundsätzlich immer zustimmungspflichtig. Wie kann der Benutzer dieses Cookie ablehnen? ?(

    Die Checkbox "Angemeldet bleiben" wurde entfernt, weil sie in 5.4 technisch keinen Nutzen mehr hat.

    Das mag ja sein, aber die Funktion bleibt wichtig, denn man sollte klar unterscheiden: Technisch zwingend notwendige Session-Cookie, um während einer Sitzung wiederkannt zu werden (ohne Zustimmung des Benutzers), und optional zu setzendes Login-Cookie (mit Zustimmung des Benutzers), um auch beim nächsten Besuch wiedererkannnt zu werden, und das möchte man höchstens auf dem eigenen Rechner verwenden.

    • Offizieller Beitrag

    Argh! Solche nicht zwingend notwendigen Cookies sind grundsätzlich immer zustimmungspflichtig. Wie kann der Benutzer dieses Cookie ablehnen? ?(

    Das entspricht leider nicht den Tatsachen. Die Zustimmungspflicht basiert auf der Art des Cookies bzw. dessen Verwendung.

    Der von uns gesetzte Cookie enthält lediglich die kryptografisch signierte Session-ID. Diese wiederum ist ein elementarer Bestandteil der Funktionsweise der Software und fällt in die Kategorie der technisch zwingend notwendigen Cookies.

    Beim Login wird lediglich Server-seitig vermerkt, dass die Session-ID X nun als Benutzer Y angemeldet ist. Der Cookie im Browser bleibt damit unverändert, dort steht weiterhin nur die Session-ID drin.

    Es gibt keine Speicherung der Zugangsdaten im Cookie mehr, diesen Passus kannst du somit bei dir speichern.

  • Okay, also gleich mal überprüfen, welche Cookies wir verwenden. Aber zuvor eine kurze Anmerkung, wie ihr das bzw. wie ihr das nicht komuniziert, denn bei kleineren Projekten kann man sowas eher entspannt sehen, es sei denn man steht gerade unter Beobachtung des LDSB, aber spätestens im beruflichen Umfeld, und da gibt es ja auch den einen oder anderen größeren Kunden, werden üblicherweise solche Änderungen langfristig vorher angekündigt, damit Informationssicherheit, Datenschutz und Betriebs- bzw. Personalrat ihre Stellungnahme dazu abgeben können. Bereits aus Sicht der Informationssicherheit kann man generell nur empfehlen, die bisherige Option und jetzige Vorgabe, stets angemeldet zu bleiben, höchstens auf dem eigenen Rechner und mit dem eigenen Benutzer zu verwenden, und sollte eigentlich ganz davon abraten. Gesetzt werden aktuell vier Cookies.

  • Der von uns gesetzte Cookie enthält lediglich die kryptografisch signierte Session-ID. Diese wiederum ist ein elementarer Bestandteil der Funktionsweise der Software und fällt in die Kategorie der technisch zwingend notwendigen Cookies.

    Wir sprechen vom Cookie „wcf_user_session“?

    Beim Login wird lediglich Server-seitig vermerkt, dass die Session-ID X nun als Benutzer Y angemeldet ist. Der Cookie im Browser bleibt damit unverändert, dort steht weiterhin nur die Session-ID drin.

    Okay, wenn ich das richtig verstehe, dann erkennt die Suite ein bereits vom jeweiligen Benutzer oder von einem anderen Benutzer verwendetes Endgerät, und kann den Fingerprint („Session-ID“) dem jeweils gerade angemeldeten Benutzer zuordnen. Das versucht man doch eigentlich mit allen Mitteln zu verhindern. Ich habe vorhin mal in eure Datenschutzerklärung geschaut, und gehofft dort eine verständliche Erklärung für die Cookies zu finden, aber dort wird nur ganz grob erklärt, was Cookies sind, und dass es sich bei den meisten von euch gesetzten Cookies um Session-Cookies handelt (was offensichtlich nicht zutrifft).

    Es gibt keine Speicherung der Zugangsdaten im Cookie mehr, diesen Passus kannst du somit bei dir speichern.

    Jain. Die beiden Cookies „wcf_password“ und „wcf_userID“ bleiben erhalten. Wir müssen wohl oder übel erstmal weiter darüber informieren. Und dann ist da ja noch ein Cookie „XSRF-Token“. Wenn es tatsächlich tut, was der Name verspricht, sollte man dessen Funktion leicht erklären können.

    Das beantwortet die Frage aber in keiner Weise. Denn du hast damit auf einen Beitrag geantwortet, der den rechtlichen Aspekt beachtet hat. Und der ist in dem Fall der einzige, der zählt.

    Da verlasse ich mich auf unsere Fachberater. Das führt hier auch deutlich zu weit. ?(

  • Passwort und UserID stammen aus ESC 5.3 und früher-Zeiten. Du kannst die Cookies löschen.

    Seit WSC 5.4 werden diese Cookies weder verarbeitet noch gesetzt.

    Deren Existenz in der Software bei jedem Aufruf zu prüfen und die zu löschen wäre sinnlos verschwendete Performance.

    Wenn du aus der "technischen Informationssicherheit" kommst, ist mir aber unerklärlich, warum du das erst Jahre nach der Benutzung der Cookies feststellst und nicht bereits im WSC untersucht hast, wofür sie dienen oder hier nachgefragt hast, was eventuell zu beachten ist.

  • Ich klinke mich hier mal mit ein, also wenn man das wiedererkennen eines Benutzers via Session-ID als Fingerprinting einstuft, wäre so ziemlich jede moderne Webanwendung davon betroffen.

    Aus der Erklärung von Alexander lese ich ein mittlerweile gängiges Verhalten heraus, bei dem Statt UserID/Passwort eben die Session-ID gespeichert wird. Fingerprinting ist das keines, dafür müsste der Cookie neben einer verschlüsselten Session-ID ja noch andere Daten aufweisen.

    Projekte:

    XIVDATA - Eorzea Database

    A red dragon falls from the heavens... Ah, that memory has been lost. A shame. It was a favorite of mine...

  • Passwort und UserID stammen aus ESC 5.3 und früher-Zeiten. Du kannst die Cookies löschen.

    Seit WSC 5.4 werden diese Cookies weder verarbeitet noch gesetzt.
    Deren Existenz in der Software bei jedem Aufruf zu prüfen und die zu löschen wäre sinnlos verschwendete Performance.

    Ja, hatte ja Alexander Ebert bereits erklärt, aber wie entferne ich sie einmalig bei den Benutzern wie von dir angesprochen?

    Wenn du aus der "technischen Informationssicherheit" kommst, ist mir aber unerklärlich, warum du das erst Jahre nach der Benutzung der Cookies feststellst und nicht bereits im WSC untersucht hast, wofür sie dienen oder hier nachgefragt hast, was eventuell zu beachten ist.

    Jahre? Das Update ist vor gerade mal einem Monat erschienen. Wir informieren sehr detailliert, auf welcher Grundlage und zu welchen Zwecken wir Cookies setzen, aber die Änderung hat uns kalt erwischt. ?(

    Ich klinke mich hier mal mit ein, also wenn man das wiedererkennen eines Benutzers via Session-ID als Fingerprinting einstuft, wäre so ziemlich jede moderne Webanwendung davon betroffen. [...] Aus der Erklärung von Alexander lese ich ein mittlerweile gängiges Verhalten heraus, bei dem Statt UserID/Passwort eben die Session-ID gespeichert wird.

    Also ich hatte das oben so verstanden, dass eine vorhandene Session-ID des jeweiligen Browsers einem neuen Benutzer zugeordnet wird, wenn sich ein Benutzer ab- und einer anderer anmeldet, und das nennt man halt Browser-Fingerprinting („Der Cookie im Browser bleibt damit unverändert, dort steht weiterhin nur die Session-ID drin.“).

    Aber das lässt sich ja testen: Beim ersten Aufruf wird eine Session-ID als Session Cookie gespeichert. Meldet man sich als Benutzer an, wird eine neue Session-ID als Persistant Cookie gespeichet. Meldet man diesen Benutzer ab, wird dieses Persistant Cookie gelöscht und ein Session Cookie gesetzt, meldet man anschließend einen anderen Benutzer an, wird wiederum eine neue Session-ID vergeben und als Persistant Cookie gespeichert.

    Es existieren wohl keine weiteren Sicherheitsvorkehrungen. Kopiert man die Session-ID von einem Browser in einen anderen Browser, ist man dort ebenfalls angemeldet, ganz ohne zweiten Faktor oder sonstige Hürden. Deshalb auch lieber keine Screenshots. Man solle sich also unbedingt nach jedem Besuch sauber abmelden. Auch bzw. insbesondere als Administrator.

    Fingerprinting ist das keines, dafür müsste der Cookie neben einer verschlüsselten Session-ID ja noch andere Daten aufweisen.

    Auch ein physischer Fingerabdruck hat erstmal keine zusätzlichen Informationen. :/

    • Offizieller Beitrag

    Also ich hatte das oben so verstanden, dass eine vorhandene Session-ID des jeweiligen Browsers einem neuen Benutzer zugeordnet wird, wenn sich ein Benutzer ab- und einer anderer anmeldet, und das nennt man halt Browser-Fingerprinting („Der Cookie im Browser bleibt damit unverändert, dort steht weiterhin nur die Session-ID drin.“).

    Nein, um es noch einmal klar zustellen: Es ist kein Fingerprinting. Wenn du einen gegenteiligen Eindruck hast, dann ist dieser falsch.

    Bist du ein Gast, so bekommst du eine Session-ID zugewiesen. Diese wird nach 2 Stunden Inaktivität vom Server gelöscht, danach existiert zwar weiterhin der Cookie im Browser, der Server kann damit aber nichts mehr anfangen und vergibt bei einem erneuten Besuch eine neue Session-ID.

    Als angemeldeter Benutzer bleibt die Session auf dem Server für 14 Tage bestehen, bevor diese verworfen wird. Ruft man die Seite innerhalb dieses Zeitraums erneut auf, verlängert sich die Session wieder um 14 Tage. Das entspricht dem "angemeldet bleiben".

    Beim Cookie "XSRF-Token" handelt es sich um einen Zusatzcookie, der direkt mit der Session verbunden ist und als Schutzmaßnahme gegen "Cross-Site-Request-Forgery"-Angriffe dient. Auch hierbei handelt es sich um einen technisch notwendigen Cookie, der nicht zustimmungspflichtig ist.

  • Als angemeldeter Benutzer bleibt die Session auf dem Server für 14 Tage bestehen, bevor diese verworfen wird. Ruft man die Seite innerhalb dieses Zeitraums erneut auf, verlängert sich die Session wieder um 14 Tage. Das entspricht dem "angemeldet bleiben".

    Das scheint nicht korrekt zu sein. Das entsprechende Cookie wurde bei mir am 17. Juli, also dem Zeitpunkt des Updates, gesetzt, und läuft am 20. Dezember ab. Das sind etwas mehr als 14 Tage. ;)

    Beim Cookie "XSRF-Token" handelt es sich um einen Zusatzcookie, der direkt mit der Session verbunden ist und als Schutzmaßnahme gegen "Cross-Site-Request-Forgery"-Angriffe dient. Auch hierbei handelt es sich um einen technisch notwendigen Cookie, der nicht zustimmungspflichtig ist.

    Man benötigt keine Zustimmung aber muss seine Nutzen dennoch informieren. Da werde ich mich später noch einlesen. :)

  • Das scheint nicht korrekt zu sein. Das entsprechende Cookie wurde bei mir am 17. Juli, also dem Zeitpunkt des Updates, gesetzt, und läuft am 20. Dezember ab. Das sind etwas mehr als 14 Tage. ;)

    Bist du ein Gast, so bekommst du eine Session-ID zugewiesen. Diese wird nach 2 Stunden Inaktivität vom Server gelöscht, danach existiert zwar weiterhin der Cookie im Browser, der Server kann damit aber nichts mehr anfangen und vergibt bei einem erneuten Besuch eine neue Session-ID.


    Als angemeldeter Benutzer bleibt die Session auf dem Server für 14 Tage bestehen, bevor diese verworfen wird. Ruft man die Seite innerhalb dieses Zeitraums erneut auf, verlängert sich die Session wieder um 14 Tage. Das entspricht dem "angemeldet bleiben".

    ;)

  • Alles schön und gut, aber was wird aus meinem Wunsch?

    Lässt es sich irgendwie wieder umsetzen, dass der Haken, eingeloggt zu bleiben, aktiv gesetzt werden muss, so dass man sich ansonsten beim nächsten Besuch wieder einloggen muss? :/

  • Also ich hoffe sehr darauf. Das dürfte sehr vielen Nutzern nicht bewusst sein, dass sie angemeldet bleiben, und dadurch ggf. andere Benutzer des Rechners ebenfalls Zugriff auf ihr Benutzerkonto erhalten, oder schlicht hin und wieder vergessen sich anschließend sauber abzumelden. Eine solche Checkbox ist heute Standard. Und das Verhalten der WoltLab Suite äußerst überraschend.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!