Web-Speicher

Wir greifen auf folgende Bereiche des Web-Speichers Ihres Browsers zu:

• Cookies
• Local Storage

Essenzielle Cookies

• Wir verwenden das Cookie _session_id, um spätestens nach einer Anmeldung (oder Registrierung) eine Referenz zu den Sitzungsdaten herzustellen. Die eigentlichen Sitzungsdaten werden jedoch auf dem Server gespeichert. Die Erstellung einer key.matiq-Box oder die Anmeldung an sie ist ohne Cookies nicht möglich. Gleiches gilt für Tickets, die zum Wiedererlangen eines verlorengegangen Zugriffs nötig sind.

  Nicht immer löscht der Browser dieses Cookie automatisch nach Sitzungsende. Denn dann könnte er einen kürzlich geschlossenen Tab nicht wieder herstellen. key.matiq löscht jedoch spätestens nach acht Stunden die auf dem Server gespeicherten Daten einer inaktiven Sitzung, so dass der Bezug zum Cookie verloren geht. Beim nächsten Besuch wird dann das Cookie gelöscht oder durch ein neues überschrieben.

  Für Besucher*innen von key.matiq, die nur die Informationsseiten aufrufen, wird das _session_id-Cookie gar nicht erst nicht erstellt.

• Das Cookie cookie_approvals vermerkt Ihre Zustimmung zu funktionalen Cookies. Ist das Cookie nicht vorhanden, werden keine funktionalen Cookies verwendet. Ansonsten listet das Cookie im Wesentlichen die genehmigten Cookie-Namen auf.

  Hinzukommen Einstellungen, die die Speicherdauer der Cookies betreffen, aber auch ein Hinweis, für welchen Kontext die Genehmigungen gegeben wurden (für eine Box, ein Ticket oder nur das lokale Gerät) und Zeitpunkte von Genehmigungen.

  Letzte Daten sind wichtig, um konkurrierende Einstellungen z. B. für die Box und das lokale Gerät aufzulösen, d. h. immer die zuletzt von der Benutzer*in Genehmigungen (bzw. deren Verweigerung) Priorität zu geben Details werden weiter unten in Konkurrierende Einstellungen behandelt.

  Es ist somit essenziell, sobald ein nicht-essenzielles funktionales Cookie erlaubt wurde. Es ist aber auch noch nötig, wenn sämtliche Genehmigungen widerrufen wurden, da dann der Zeitpunkt des Widerrufs abgespeichert werden muss.

• Das Cookie guest markiert, dass ein Gastzugang eingerichtet wurde. Es enthält als Wert den Zeitstempel (UTC) der Erstellung und den Wert des Cookies cookie_approvals. Beim Abschalten des Gastzugangs wird das Cookie guest wieder gelöscht und das Cookie cookie_approvals mit seinem ursprünglichen Wert wiederhergestellt. Da der Gastzugang immer explizit abgeschaltet werden sollte, bleibt das Cookie ohne die Abschaltung langfristig (5 Jahre) bestehen.

  Das Cookie guest ist essenziell, sobald ein Gastzugang benötigt wird und existiert auch nur für diese Zeit.

Unter den drei essenziellen Cookes enthält nur _session_id ein kritisches Datum (nämlich den Bezug zu den auf dem Server gespeicherten Sitzungsdaten), verliert aber durch Timeouts, die zur Sperrung oder Löschung der Sitzungsdaten führen, seinen Wert für Angreifer*innen.

Die beiden anderen Cookies haben für Angreifer*innen kaum Wert. Die Werte von cookie_approvals könnten noch am ehesten interessant sein, da sie Hinweise darüber geben, welche Sicherheitsmaßnahmen die Besitzer*in vielleicht ergriffen hat. Aber diese Information ergibt sich bereits daraus, welche der nicht-essenziellen Cookies existieren oder nicht existieren.

Nicht-essenzielle funktionale Cookies ...

... zur Erhöhung Ihrer Sicherheit*

• Das Cookie autocomplete wird benötigt, um festzustellen, ob der Passwortmanager Ihres Browsers das Anmeldeformular vorab ausfüllen darf (Normalfall) oder nicht (nach einem Sitzungstimeout oder nach dem Neusetzen des Cookies). Bezogen auf das Cookie wird auf dem Server lediglich gespeichert, ob bzw. wann die Verwendung des Passwortmanagers des Browsers wieder erlaubt ist. Nur mit diesem Cookie und den darauf bezogenen Daten bietet ein Sitzungstimeout auch dann noch (eine limitierte) Sicherheit, wenn der Passwortmanager des Browsers benutzt wird. Letzterer ist wichtig, da sonst die Verwendung sicherer Hauptkennwörter, insbesondere auf Handys, erschwert würde.
  (Hinweis: Für Tickets ist die Verwendung dieses Cookies noch nicht implementiert aber geplant.)
• Mit dem Cookie box_id stellen wir eine Beziehung zwischen Ihrem Gerät und Ihrer Box bereits vor der Anmeldung her. Damit können wir Ihnen einen von Ihnen gewählten Willkommensspruch auf der Anmeldeseite anzeigen, um Phishing-Angriffe auf Ihre Box zu erschweren. Es erleichtert uns auch, mögliche Erkundungs-Angriffe zu erkennen und diese abzuwehren, ohne Sie allzuoft mit Captchas zu belästigen.
• Das Cookie device_id dient der Zwei-Faktor-Authentisierung. Es wird nur erstellt, wenn Sie von Ihrem Gerät aus eine Box registrieren oder sich in ihr anmelden. In der Box wird über diese ID das Gerät als Ihnen zugehörig registriert. Sobald Sie die Zwei-Faktor-Authentisierung einschalten, werden zukünftige Anmeldungen auf die registrierten Geräte begrenzt. Falls Sie ein Gerät verlieren, können Sie über ein anderes registriertes Gerät oder ein Ticket das verlorene Gerät von der Liste löschen und damit die Anmeldung in Ihrer Box von diesem Gerät aus unterbinden.***.
• Das Cookie ticket_id entspricht dem Cookie box_id und dient der Abwehr von möglichen Erkundungs-Angriffen, wenn Sie (z. B. um den Zugang zu Ihrer Box wiederherzustellen) ein Ticket angelegt haben

... für optimale Bedienbarkeit und verständliche Dokumentation

• Wir speichern in dem Cookie device Ihre Angaben zu Ihrem Gerät ab (z. B. ob es einen Sen­sor­bild­schirm enthält oder eine Tastatur mit Maus), um Ihnen eine optimale Darstellung und Bedienoberfläche bieten zu können und die Dokumentation auf Ihre Gegebenheiten anzupassen. Diese Daten speichern wir langfristig (fünf Jahre) ab, um Sie auch nach langem Verzicht auf Besuche nicht mit erneuten Fragen nach diesen Daten belästigen zu müssen.

... für Ihre Bequemlichkeit

• Das Cookie browser_tested wird benutzt, um festzustellen, ob Ihr Browser bereits für key.matiq getested wurde.
  Mit dem Cookie können wir erkennen, ob und wann wir Sie schon einmal gewarnt haben, dass key.matiq möglicherweise nicht mit Ihrem Browser funktioniert.
  Ohne das Cookie müssten wir sie bei jedem Besuch aufs Neue warnen, weil wir dann nicht wissen können, dass dies längst erfolgt ist. Mit dem Cookie können wir uns darauf beschränkten, die Warnung in vertretbaren Abständen zu wiederholen.

Risiken bei kurzen Gültigkeitszeiträumen von Cookies

• Es kann zu Anmeldesperren kommen, wenn die Zwei-Faktor-Authentisierung verwendet wird.
• Benutzer*innen könnten dann evtl. auf die Zwei-Faktor-Authentisierung verzichten, um dieses Problem zu umgehen. Besser wäre es aber in der Regel, die Gültigkeit zu verlängern.
• Die Personalisierung durch eine Willkommensnachricht könnte nicht mehr funktionieren und damit würden Phishing-Angriffe erleichtert.
• Geräte-Einstellungen könnten verloren gehen und damit Benutzer beim Lesen von Handbuchseiten leicht verwirren.
• Die Information über neue Informationsseiten würde evtl. nicht mehr funktionieren.
• Warn-Hinweise über fehlgeschlagene Browser-Tests könnten zu häufig oder zu selten erscheinen.

Risiken bei langen Gültigkeitszeiträumen von Cookies

Wenn ein Gerät verschenkt oder entsorgt wird und dabei vergessen wird, die privaten Daten zu löschen oder die Festplatte komplett zu zerstören, könnten die Cookies in falsche Hände geraten:

• Der zweite Faktor bei einer Zwei-Faktor-Authentisierung würde für das Gerät ausgehebelt. Allerdings wäre es möglich über die Einstellungen das Gerät von einem anderen Gerät aus zu sperren. (Cookie: device_id)
• Die Personalisierung über die Willkommensnachricht hängt von dem Cookie box_id ab. Dieses könnte für Phishing-Angriffe missbraucht werden.

Nicht mehr benutzte Cookies

Nicht mehr benutzt werden die Cookies:

• _tmp
• cookie_eu_consented
• latest
• token

Konkurrierende Einstellungen

Im Cookie "cookie_approvals", aber auch in einer Box oder einem Ticket sollten Genehmigungen für nicht-essenzielle Cookies in der Box gespeichert werden, die diese Genehmigungen dann bei einer Anmeldung in das Cookie "cookie_approvals" überträgt.

Dadurch, dass key.matiq bereits beim Cookie "device" die Genehmigung frühzeitig bekommen sollte (vor der Anmeldung, um eine gute Lesbarkeit der Infoseiten bereits zu diesem Zeitpunkt zu erhalten) und auch außerhalb der Anmeldung es möglich sein sollte, für das Gerät eine Genehmigung zu widerrufen, ergib sich das Problem, dass Cookie-Einstellungen der Box und für das lokale Gerät auseinanderlaufen können, aber auch dürfen müssen.

Wenn man in einer Box eine Cookie-Genehmigung erteilt oder zurückzieht, so erfolgt auf dem lokalen Gerät diese Änderung ebenfalls. Eine spätere Anmeldung an einem anderen Gerät verlangt aber, dass auch für dieses Gerät die Änderung übernommen wird, aber nur dann, wenn auf diesem anderen Gerät dort nicht zwischenzeitlich die betroffene Genehmigung lokal geändert wurde. Deshalb benötigt key.matiq in den Box-Einstellungen, aber auch im Cookie "cookie_approvals" Timestamps über allgemeine und teilweise Veränderungen der Cookie-Einstellungen.

Allgemein erfolgen die Veränderungen über die Seite "Einstellungen > Cookies", teilweise erfolgen sie, wenn bei Bearbeitung anderer Einstellungen die Genehmigung eines einzelnen Cookies erfolgt, um eine spezielle Funktioonalität zu ermöglichen. (Letzteres ist sehr sinnvoll, da sich damit der Benutzer*in direkt der Sinn eines Cookies erschließt und so vermieden wird, dass aus Unkenntnis heraus Cookies-Genehmigungen verweigert werden.)

Auch wenn diese Implementation recht kompliziert ist, haben wir uns dafür entschieden, da die Benutzer*in selbst in der Regel kaum etwas von der Komplexität erfährt, ihr unliebsame Überraschungen erspart bleiben, und es für sie recht einfach bleibt:

Sie genehmigt in der Regel das "device"-Cookie vor Registrierung oder Anmeldung und wird um Zustimmung zu weiteren Cookies während der Registrierung oder nach einer Anmeldung gebeten, wenn es erforderlich ist.

Eine fortgeschrittene Benutzer*in kann über die Einstellungen Cookies löschen, wenn sie es will, wird aber dabei jeweils über die Konsequenzen aufgeklärt.

Alles ist DSGVO-konform und flexibel implementiert (jedes Cookie erfüllt genau eine Aufgabe und lässt sich einzeln erlauben bzw. verbieten), so dass keine Probleme bestehen, sollten z. B. weitere Cookies erforderlich werden.

Local Storage

In dem Local Storage werden die folgenden Datensätze gehalten:

• "session": Hier werden Schlüssel und andere geheime Daten während einer Sitzung über mehrere Tabs und Seiten hinweg gehalten, um Geheimnisse, die verschlüsselt auf dem Server gehalten werden oder werden sollen, ent- bzw. verschlüsseln zu können. Die session-Daten sind ihrerseits verschlüsselt. Nach dem Ende einer Sitzung können sie, auch wenn sie evtl. nicht gelöscht werden konnten, jedenfalls nicht mehr entschlüsselt werden, da zumindest ein wesentlicher Teil-Schlüssel dafür unwiderbringlich vergessen wurde.
• "session_key": Dies ist einer von zwei Teil-Schlüsseln für die Ent- und Verschlüsselung der "session"-Daten. Ist er gelöscht, ist die Sitzung zumindest gesperrt und kann ohne neue Hauptkennwort-Eingabe nicht mehr fortgesetzt werden.
• "session_status": Dieser Eintrag ist vorhanden, falls eine Anmeldung in eine Box oder in ein Ticket in einem Tab erfolgt ist und dient dazu, andere mögliche Tabs darüber zu informieren. Nach einer Abmeldung wird er gelöscht und dadurch auch alle anderen Tabs entsprechend informiert.
• "auth_lock": Dieser Eintrag ist während einer Anmeldeprozedur vorhanden, um zu verhindern, dass parallele Anmeldeprozeduren auf mehreren Tabs laufen.

Bei der nächsten Sitzung werden die im Local Storage enhaltenen Daten komplett überschrieben.

*) Es geht hier um "Unaufdringliche Sicherheit", die durch Cookies möglich ist. Da Cookies manipulierbar sind, funktionieren sie meist so: Es werden Funktionen erschwert (zusätzliche "aufdringliche" Sicherheitsabfragen oder -aktionen), wenn Cookies gelöscht oder manipuliert wurden, aber erleichtert, wenn Cookies vorhanden sind und gültige Inhalte haben.
Das funktioniert aber nur, wenn diese Cookies grundsätzlich (d. h. auf Box- oder Ticket-Ebene) erlaubt sind. , Anderenfalls werden die zugehörigen Sicherheitsfeaturen abgeschaltet, um die Bedienbarkeit nicht unzumutbar einzuschränken.

**) Sie Sicherheit ist limitiert, da es versierten Hacker*innen möglich wäre, eine offene Browsersitzung so zu manipulieren, dass die Sperrung der Autovervollständigung umgangen werden könnte. Für weniger versierte Personen dürfte die Sperrung aber durchaus ein Hindernis sein. Grundsätzlich ist die zusätzliche Einstellung eines PC-Sitzungstimeouts zu empfehlen.

***) Das ist zwar auch noch möglich, wenn Sie zuvor das Cookie device_id abgelehnt hatten. (Man müsste zunächst das Cookie aktivieren, sich auf allen Geräten, die man noch besitzt, in der key.matiq-Box anmelden und dann die Zwei-Faktor-Authentisierung anschalten. Dann wäre das verloren gegangene Gerät ausgesperrt.) Aber es ist viel einfacher, vorher schon präventiv alle Geräte, die Sie mit key.matiq benutzen, zu registrieren und diesen Geräten auch Namen zu geben. Dann brauchen Sie lediglich das verlorene Gerät aus der Geräteliste entfernen und Sie laufen nicht so leicht Gefahr, sich in dieser Stresssituation selbst auszusperren.