Session-Management

Dieser Artikel erklärt, wie Ephraim angemeldete Sitzungen begrenzt, verlängert, rotiert und beendet. Er richtet sich an Admins und technische Betreuung, die einschätzen müssen, wo Vault-Schlüssel während einer Sitzung liegen, wann eine Anmeldung abläuft und welche Rolle Cron dabei wirklich spielt.

· Stand: Juni 2026

1. Zielbild

Kurzfassung: Ephraim verlängert Sitzungen nur nach echter Nutzeraktivität. Eine Sitzung läuft nach 45 Minuten Inaktivität ab, spätestens aber nach 12 Stunden. Die native Browser-Sitzung wird regelmäßig rotiert und serverseitig nur als HMAC gebunden, nicht im Klartext gespeichert.

Eine Sitzung ist in Ephraim mehr als ein Login-Cookie. Während der Anmeldung hängen daran Rollen, CSRF-Schutz, Vault-Entsperrung, Zwei-Faktor-Zustände, Aktivitätsfristen und die Frage, ob ein alter Browser-Tab noch vertrauenswürdig ist. Deshalb trennt Ephraim mehrere Ebenen: das Browser-Cookie, die verschlüsselte PHP-Session, die Sitzungsübersicht, den aktuell gültigen nativen Session-ID-Hash und die tatsächliche Aktivität im Browser.

Für Admins ist die wichtigste Konsequenz: Ablauf und Sicherheit hängen nicht vom Gefühl „die Seite ist noch offen“ ab. Eine offene Seite reicht nicht. Ephraim verlangt eine gültige serverseitige Sitzung, eine passende native Session-ID und eine bestätigte Aktivitätsverlängerung innerhalb der Idle-Frist.

2. Begriffe

Begriff Bedeutung in Ephraim Admin-Relevanz
Native PHP-Session-ID Der technische Bezeichner, den der Browser als Cookie mitschickt. Wird regelmäßig erneuert und nicht im Klartext in der Datenbank gespeichert.
Logische Sitzung Der serverseitig registrierte Anmeldezustand eines Nutzers. Bleibt über eine native Session-ID-Rotation hinweg dieselbe fachliche Anmeldung.
Sessiontoken-Hash Ein zufälliger Prüfwert für die Sitzungsübersicht. Erlaubt Widerruf und Anzeige aktiver Sitzungen, ohne den Token selbst zu speichern.
Native Session-ID-HMAC Serverseitiger HMAC der aktuell gültigen nativen PHP-Session-ID. Bindet die logische Sitzung an genau die aktuelle Browser-Sitzung.
Idle-Timeout Ablauf nach 45 Minuten ohne bestätigte Aktivität. Schützt offene Geräte, vergessene Tabs und verlassene Arbeitsplätze.
Absolute Obergrenze Spätester Ablauf nach 12 Stunden seit Sitzungsanlage. Verhindert unbegrenzt gleitende Dauersitzungen.
Aktivitäts-Heartbeat Ein CSRF-geschützter Hintergrundaufruf nach echter Nutzeraktivität. Nur dieser Aufruf verlängert die Idle-Frist und löst bei Bedarf Rotation aus.

3. Lebenszyklus einer Anmeldung

Der Lebenszyklus beginnt mit Passwortprüfung, Vault-Entsperrung und optionaler Zwei-Faktor-Prüfung. Nach erfolgreicher Anmeldung erhält der Browser eine frische native Session-ID. Ephraim registriert die logische Sitzung serverseitig, speichert Hashwerte und setzt die erste Idle-Frist. Danach verlängert nicht jeder Seitenaufruf automatisch die Sitzung; Verlängerung passiert über den Aktivitäts-Heartbeat.

Lebenszyklus einer Ephraim-Sitzung Die Anmeldung führt über Passwort, optional 2FA, finale Sitzung, Aktivitätsheartbeat, Rotation und Ablauf oder Logout. Passwort prüfen und Vault entsperren Optional 2FA 10 Minuten Zwischenfrist Finale Sitzung Token-Hash und native ID-HMAC Aktivität trusted Event plus CSRF Verlängern Idle-Frist bis max. 12 Stunden Ablauf Idle, 12h-Grenze oder Widerruf Rotation native ID nach 45 Minuten aktiv Prüfung und Verlängerung sind getrennt: normale geschützte Requests validieren nur, der Heartbeat verlängert.
Die Sitzung wird nach Anmeldung registriert, über echte Aktivität verlängert und regelmäßig an eine neue native Session-ID gebunden. Ablauf ist eine Prüfentscheidung, kein Cron-Ereignis.

4. Zeitregeln

Ephraim nutzt mehrere Fristen, weil jede Frist ein anderes Risiko adressiert. Die Idle-Frist schützt verlassene Geräte. Die absolute Grenze verhindert unbegrenztes Weiterschieben. Die Rotationsfrist begrenzt die Lebensdauer einer nativen Session-ID. Die 2FA-Zwischenfrist verhindert, dass eine halb abgeschlossene Anmeldung mit bereits entsperrtem Vault-Material lange offen bleibt.

Frist Dauer Startpunkt Was passiert beim Erreichen?
Inaktivität 45 Minuten Letzte bestätigte Nutzeraktivität Die Sitzung wird bei der nächsten Prüfung abgewiesen; der Nutzer muss sich neu anmelden.
Absolute Obergrenze 12 Stunden Anlage der logischen Sitzung Keine weitere Verlängerung; auch aktive Nutzer müssen danach neu anmelden.
Native Session-ID-Rotation 45 Minuten aktiver Nutzung Letzte native ID-Erneuerung Der Browser bekommt eine neue native Session-ID; der serverseitige HMAC wird aktualisiert.
2FA-Zwischenzustand 10 Minuten Erfolgreiche Passwortprüfung bei aktivierter 2FA Der Zwischenzustand wird verworfen, einschließlich temporärem Vault-Material.
Wichtig für Supportfälle: „Ich war doch noch auf der Seite“ ist nicht dasselbe wie „die Sitzung wurde verlängert“. Verlängert wird erst, wenn der Browser eine echte Aktivität meldet, der Tab sichtbar ist, CSRF passt und die serverseitige Sitzung noch gültig ist.

5. Was wo gespeichert ist

Die häufigste Admin-Frage betrifft den Vault-Schlüssel: Er darf nicht unverschlüsselt auf der Serverplatte landen. Ephraim trennt deshalb zwischen Browser-Cookie, verschlüsselter Sessiondatei, Datenbank-Metadaten und kurzlebigem RAM während eines Requests.

Speicherorte im Session-Management Browser, PHP-Prozess, verschlüsselte Sessiondatei, Datenbank und Cron speichern unterschiedliche Teile der Sitzung. Browser Cookie mit nativer Session-ID kein Vault-DEK PHP-Prozess Klartext nur während des aktuellen Requests inklusive Vault-DEK PHP-Sessiondatei verschlüsselter Session-Payload kein Klartext-DEK Datenbank Token-Hash, native ID-HMAC, Zeiten Browser/IP gekürzt Heartbeat echte Aktivität, CSRF, kein Client-Zeitstempel verlängert serverseitig Cron räumt alte Einträge der Übersicht auf entscheidet keinen Ablauf Alte verschlüsselte Sessiondateien können bis zur Aufräumfrist existieren, werden aber ohne gültige Zeit- und HMAC-Prüfung nicht akzeptiert.
Klartext existiert nur kurz im aktuellen Serverprozess. Persistente Sessiondaten liegen verschlüsselt oder als Hash/HMAC vor; Cron bereinigt später nur Altlasten.
Ort Typischer Inhalt Vault-Schlüssel im Klartext?
Browser-Cookie Native Session-ID, geschützt durch HttpOnly und SameSite. Nein.
PHP-Prozess während eines Requests Aus der Session entschlüsselte Nutzer- und Vault-Daten für die aktuelle Verarbeitung. Ja, kurzzeitig im RAM, solange der Request verarbeitet wird.
PHP-Session-Speicher Verschlüsselter Session-Payload, darunter Rollen, CSRF und bei entsperrtem Vault auch verschlüsseltes Vault-Material. Nein, nicht als Klartextdatei.
Sitzungsübersicht Token-Hash, native Session-ID-HMAC, Zeitpunkte, gekürzte IP-/Browserhinweise. Nein.
Cron-Aufräumung Löscht abgelaufene, widerrufene oder veraltete Übersichtseinträge. Nein; Cron entscheidet nicht über die aktuelle Gültigkeit.

6. Sicherheitsfragen klar beantwortet

Die folgenden Antworten sind bewusst zweigeteilt. Die Kurzantwort beschreibt, was für Nutzerinnen, Nutzer und Datenschutzgespräche wichtig ist. Die technische Einordnung beschreibt, welche Prüfung oder welcher Speicherort dahintersteht.

Frage Kurzantwort für Laien Technische Einordnung
Gibt es während der Sitzung eine Datei mit dem Vault-Schlüssel im Klartext? Nein. Auf der Serverplatte soll keine Klartextdatei mit dem persönlichen Vault-Schlüssel liegen. Die PHP-Sessiondatei enthält einen verschlüsselten Session-Payload. Der persönliche DEK wird beim Verarbeiten einer Anfrage im PHP-Prozess entschlüsselt, aber nicht als Klartextdatei persistiert.
Was bedeutet „nur im RAM“ genau? Der Schlüssel wird während einer konkreten Aktion benötigt, zum Beispiel um eine private Datei oder einen Chat zu entschlüsseln. Danach soll er nicht dauerhaft gespeichert bleiben. Während eines Requests liegt der entschlüsselte Sessioninhalt im Arbeitsspeicher des PHP-Prozesses. Das schützt nicht gegen einen vollständig kompromittierten Server oder einen Angreifer mit Live-Zugriff auf den Prozessspeicher, reduziert aber das Risiko bei Datenbank- oder Plattenabzügen.
Ist die Datei nach Ende der Sitzung sofort weg? Beim Logout oder Ablauf wird die Anmeldung beendet. Eine alte technische Sessiondatei kann noch bis zur normalen Aufräumung existieren, ist aber verschlüsselt und nicht mehr als gültige Anmeldung nutzbar. Die lokale PHP-Session wird verworfen beziehungsweise zerstört. Zusätzlich prüfen Requests Ablaufzeit, Widerruf, Session-Version und native Session-ID-HMAC. Eine alte Datei allein reicht nicht, um die Sitzung wiederzubeleben.
Beginnen die 45 Minuten bei jeder Aktivität neu? Ja, aber nur bei bestätigter echter Nutzung. Eine nur offene Seite oder reine Hintergrundaktivität reicht nicht. Der Aktivitäts-Heartbeat akzeptiert nur vertrauenswürdige Nutzerereignisse in sichtbaren Tabs mit gültigem CSRF-Token. Der Server berechnet die neue Ablaufzeit selbst und begrenzt sie auf die absolute 12-Stunden-Grenze.
Warum gibt es zusätzlich eine 12-Stunden-Grenze? Damit eine Sitzung nicht über Tage immer weiter offen bleiben kann, selbst wenn regelmäßig etwas geklickt wird. Die Idle-Frist ist gleitend, die absolute Obergrenze nicht. Nach 12 Stunden seit Anlage der logischen Sitzung wird keine Verlängerung mehr akzeptiert.
Regelt Cron den Ablauf? Nein. Cron räumt nur später auf. Ungültig wird eine Sitzung sofort, sobald der Server sie beim nächsten Zugriff prüft. Ablauf, Widerruf, Session-Version und native HMAC-Bindung werden synchron in der Auth-Prüfung ausgewertet. Cron entfernt abgelaufene Übersichtseinträge und unterstützt damit Hygiene, nicht die Echtzeitentscheidung.
Grenze des Schutzmodells: Diese Architektur schützt insbesondere gegen Klartextfunde auf Platte, Datenbankkopien und liegengebliebene Sessiondateien. Sie ist kein Schutz gegen einen Angreifer, der den laufenden Webserver, den PHP-Prozess oder privilegierten Arbeitsspeicherzugriff bereits kontrolliert.

7. Aktivitätsverlängerung

Der sichtbare Ablauftimer unter dem Profilmenü ist ein Hinweis, nicht die Autorität. Die Autorität liegt immer auf dem Server. Der Browser meldet Aktivität nur nach echten Nutzerereignissen wie Klick, Tastatur, Eingabe, Touch, Scroll oder Formularaktion. Reine Mausbewegungen werden nicht verwendet, weil sie zu viele Scheinsignale erzeugen und Sitzungen unnötig offen halten könnten.

Der Heartbeat läuft nicht blind im Hintergrund. Ist der Tab nicht sichtbar, läuft gerade ein anderer getrackter Request, ein Upload oder ein Chat-Stream, wartet der Timer. Dadurch wird eine Session-ID-Rotation nicht mitten in parallele Abläufe gedrückt. Der Heartbeat sendet außerdem keine eigene Uhrzeit, der Server berechnet Ablauf und absolute Grenze selbst.

Admin-Merksatz: Der Timer zeigt an, wann die Sitzung aus Sicht der letzten Serverantwort endet. Verlängert wird erst, wenn der Server einen gültigen, CSRF-geschützten Aktivitätsaufruf akzeptiert.

8. Rotation und alte Tabs

Nach 45 Minuten aktiver Nutzung erneuert Ephraim die native Session-ID. Die fachliche Sitzung bleibt dieselbe, aber die alte native ID passt danach nicht mehr zum gespeicherten HMAC. Ein alter Tab, der noch mit der alten ID arbeitet, kann die logische Sitzung nicht weiter verlängern. Er verliert seine eigene lokale Anmeldung, widerruft aber nicht automatisch die frische Sitzung eines anderen Tabs.

Diese Trennung ist absichtlich. Ohne sie könnte ein verspäteter Request aus einem alten Tab eine neu rotierte Sitzung versehentlich beschädigen. Ephraim behandelt solche Fälle deshalb als lokale Ablaufentscheidung: Der alte Zugriff wird abgewiesen, die aktuelle gültige Sitzung bleibt über den neuen nativen HMAC gebunden.

Situation Ergebnis Warum
Aktiver Tab sendet rechtzeitig Heartbeat Idle-Frist wird verlängert. Aktivität, CSRF, Token und native ID passen zusammen.
Rotation ist fällig Native ID wird erneuert, HMAC wird aktualisiert. Die Lebensdauer eines technischen Session-Bezeichners bleibt begrenzt.
Alter Tab nutzt alte native ID Request wird abgewiesen; lokale Sitzung endet. Der gespeicherte HMAC passt nur noch zur neuen nativen ID.
12-Stunden-Grenze erreicht Keine Verlängerung mehr möglich. Die absolute Sitzungsdauer ist bewusst nicht gleitend.

9. Admin-Aktionen und ihre Folgen

Admins beeinflussen Sitzungen indirekt über Konto- und Sicherheitsaktionen. Besonders wichtig sind Passwort- und Resetvorgänge: Wenn ein Passwort geändert oder zurückgesetzt wird, steigt die Sicherheitsversion des Kontos. Bestehende Sitzungen mit alter Version werden danach nicht mehr akzeptiert. Die aktuelle legitime Sitzung kann auf die neue Version gehoben werden; andere Sitzungen laufen aus oder werden widerrufen.

Aktion Folge für Sitzungen Supporthinweis
Normales Logout Die aktuelle logische Sitzung wird widerrufen und die lokale PHP-Session zerstört. Das ist ein bewusster Sitzungsabschluss.
Idle- oder absolute Ablaufprüfung Die lokale Session wird verworfen; der Übersichtseintrag muss nicht sofort gelöscht sein. Ein späterer Cron-Lauf räumt alte Übersichtseinträge auf.
Passwortwechsel Andere aktive Sitzungen werden beendet; der Vault-DEK wird mit dem neuen Passwort neu verpackt. Bei geplantem Wechsel ist dies der bevorzugte Weg gegenüber Admin-Reset.
Admin-Reset Alte Passwort- und Vault-Zugriffe werden ungültig; neue Anmeldung muss den Resetfluss abschließen. Das ist ein Eingriff in den Konto-Sicherheitszustand und kein komfortabler Passwortwechsel.
2FA erforderlich oder neu eingerichtet Zwischenzustände sind kurzlebig; finale Sitzung entsteht erst nach erfolgreicher Prüfung. Abgelaufene 2FA-Seiten verlangen eine neue Anmeldung.
Andere Sitzungen beenden Der ausgewählte logische Sitzungseintrag wird widerrufen. Die eigene aktuelle Sitzung kann nicht auf diesem Weg versehentlich beendet werden.

10. Rolle von Cron

Cron ist für Session-Gültigkeit nicht der Schiedsrichter. Eine Sitzung wird abgewiesen, sobald ein Request oder Heartbeat serverseitig feststellt, dass Idle-Frist, absolute Grenze, Widerruf, Sicherheitsversion oder native ID-HMAC nicht mehr passen. Dafür muss kein Cron-Lauf vorher stattgefunden haben.

Cron räumt später auf: abgelaufene Einträge aus der Sitzungsübersicht, länger widerrufene Einträge und veraltete inaktive Zustände verschwinden aus der Datenbank. Die verschlüsselten PHP-Sessiondateien selbst folgen zusätzlich den normalen PHP-Aufräumregeln. Solange eine alte verschlüsselte Datei noch existiert, ist sie nicht automatisch eine gültige Anmeldung. Gültig wird sie nur, wenn alle serverseitigen Prüfungen bestehen.

Betriebsregel: Cron ist wichtig für Hygiene und Übersicht. Die eigentliche Sicherheitsentscheidung passiert synchron bei der nächsten Nutzung der Sitzung.

11. Diagnose im Supportfall

Bei Sitzungsfragen hilft eine klare Trennung zwischen „abgelaufen“, „widerrufen“, „rotiert“ und „lokal verloren“. Für die meisten Supportfälle reicht es, die Symptome gegen die folgenden Muster zu halten.

Symptom Wahrscheinliche Ursache Sinnvolle Admin-Frage
Nutzer wird nach Pause ausgeloggt 45 Minuten Inaktivität oder sichtbarer Tab ohne bestätigten Heartbeat. War der Nutzer wirklich aktiv oder nur die Seite geöffnet?
Nutzer wird trotz Arbeit nach einem halben Tag ausgeloggt 12-Stunden-Obergrenze erreicht. Begann die Anmeldung am Morgen oder in einem alten Tab?
2FA-Seite akzeptiert Code nicht mehr Der 10-Minuten-Zwischenzustand ist abgelaufen. Wurde nach Passwortprüfung zu lange gewartet?
Ein alter Tab verliert die Anmeldung, ein neuer bleibt aktiv Native Session-ID wurde rotiert; der alte Tab hat den alten Bezeichner. Waren mehrere Tabs lange parallel offen?
Sitzungsübersicht zeigt alte Einträge noch kurz Gültigkeit ist bereits beendet, Aufräumung folgt später. Ist Cron gelaufen und liegt der Eintrag außerhalb der Aufräumfrist?

12. Betriebs-Checkliste