Daten, Datenschutz & Sicherheit › Admin-Login & Sitzungen
Admin-Login & Sitzungen
SicherheitLive✓ Geprüft am Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)So meldet sich das Büro im Verwaltungsbereich an: Benutzername und Passwort, bei eingerichteter Zwei-Faktor-Absicherung zusätzlich ein Code aus der Authenticator-App. Danach trägt der Browser einen Sitzungsausweis: bei einem echten Benutzerkonto sieben Tage lang, beim älteren Zugang aus der Server-Einrichtung acht Stunden. Praktisch jede Verwaltungsseite hängt daran.
So arbeitest du damit
- Rufe den Verwaltungsbereich auf; es erscheint der Bildschirm „Anmeldung".
- Trage Benutzer und Passwort ein und drücke „Anmelden".
- Gib bei Konten mit Zwei-Faktor-Absicherung den sechsstelligen Code aus der Authenticator-App ein.
- Arbeite normal weiter — die Sitzung bleibt bestehen, bis sie abläuft, widerrufen wird oder du dich abmeldest.
- Melde dich an fremden oder geteilten Rechnern ausdrücklich ab, statt nur das Fenster zu schließen.
Nach erfolgreicher Anmeldung legt das System eine Sitzung an und gibt dem Browser einen Ausweis dafür mit. Bei einem echten Benutzerkonto liegt die Sitzung in der Datenbank: Sie kennt das Konto, die Rolle, den Zeitpunkt der Anlage, den letzten Zugriff und ein Ablaufdatum, und sie lässt sich jederzeit widerrufen. Bei jedem Aufruf einer Verwaltungsseite wird sie neu geprüft — widerrufen, abgelaufen oder Konto deaktiviert bedeutet sofort keinen Zugriff mehr. Aus der Rolle und einer möglichen persönlichen Abweichung ergeben sich die Rechte für genau diesen Aufruf (Wer sieht was (Rollen & Sichtbarkeit)). Daneben existiert ein älterer Weg über die in der Server-Einrichtung hinterlegten Zugangsdaten; er hat kein Konto dahinter und gilt immer als Inhaber mit vollen Rechten. Vor die Geldbereiche kann zusätzlich eine zweite PIN treten, und das Archiv verlangt ohnehin den Master-PIN des Inhabers (Vault-Sichtbarkeitsregel (Hausregel 2)).
- Anmeldung schlägt trotz richtigem Passwort fehl → Prüfen, ob das Konto noch aktiv ist; ein deaktiviertes Konto wird beim Prüfen der Sitzung abgewiesen, nicht erst beim Anmelden.
- Der Code aus der Authenticator-App wird nicht angenommen → Meist läuft die Uhr des Geräts falsch. Zeit am Telefon auf automatisch stellen und neu versuchen.
- Nutzer wird mitten in der Arbeit ausgeworfen → Die Sitzung ist abgelaufen oder wurde widerrufen. Neu anmelden; ungespeicherte Eingaben sind verloren.
- Jemand hat sich an einem fremden Rechner nicht abgemeldet → Die Sitzung dieses Kontos widerrufen, statt auf den Ablauf zu warten.
- Eine Person hat plötzlich mehr Rechte als erwartet → Möglicherweise ist sie über den alten Zugangsweg angemeldet. Der gilt immer als Inhaber.
Regelt
Enthält
- Benutzer / 2FA Teilweise
- Rollen & Rechte (Berechtigungskatalog) Live
- Anmeldung & 2FA (API) Live
Gebraucht von
Schützt
Nutzt
Gehört zu
- Benutzer / 2FA Teilweise
Genutzt von
- Der Anmeldebildschirm verspricht acht Stunden Sitzungsdauer. Das stimmt nur für den alten Anmeldeweg; eine Anmeldung mit echtem Benutzerkonto hält sieben Tage. Der Text ist damit für die meisten Anmeldungen falsch und gehört korrigiert.
- Ob der alte Anmeldeweg über die Zugangsdaten der Server-Einrichtung in der laufenden Werkstatt noch aktiv ist, sagt keine der gelesenen Quellen.
- lib/admin-auth.ts
- lib/db/sessions.ts
- lib/db/users.ts
- app/api/admin/login
- app/api/admin/logout
| cookie | kfz_admin_session, 8 Std. TTL |
|---|---|
| modus | NEU: DB-Session (kfz_sess_-Praefix) via lib/db/sessions.ts; LEGACY: signiertes HMAC-Cookie aus ADMIN_USER/ADMIN_PASS/ADMIN_SESSION_SECRET |
| mechanismus | Zwei Wege nebeneinander. Der neue führt eine Sitzung in der Datenbank (widerrufbar, an ein Benutzerkonto und seine Rolle gebunden, mit letztem Zugriff und optionaler Zwei-Faktor-Bestätigung). Der alte prüft ein signiertes Cookie aus den Zugangsdaten der Server-Einrichtung und gilt immer als Inhaber. Beide liegen im selben Sitzungsausweis im Browser; das System erkennt am Präfix, welcher gilt. |
Beleg: lib/admin-auth.ts — 'Cookie: kfz_admin_session ... ADMIN_TTL_SEC = 8*60*60'; dual-mode DB-Sessions + Legacy-HMAC
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: sec-admin-login (Sicherheit · Daten, Datenschutz & Sicherheit · live · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: So meldet sich das Büro im Verwaltungsbereich an: Benutzername und Passwort, bei eingerichteter Zwei-Faktor-Absicherung zusätzlich ein Code aus der Authenticator-App. Danach trägt der Browser einen Sitzungsausweis: bei einem echten Benutzerkonto sieben Tage lang, beim älteren Zugang aus der Server-Einrichtung acht Stunden. Praktisch jede Verwaltungsseite hängt daran.
Lies zuerst (Lesebereich, nicht der ganze Baum):
lib/admin-auth.ts
lib/db/sessions.ts
lib/db/users.ts
app/api/admin/login
app/api/admin/logout
Hängt zusammen mit:
app-admin-crm (app/admin/layout.tsx) · feat-benutzer (app/admin/benutzer/page.tsx) · feat-cockpit (app/admin/page.tsx) · feat-eigene-aufgaben (app/api/admin/own-tasks/route.ts) · comp-rollen-sichtbarkeit (lib/admin-auth.ts) · app-admin-crm (app/admin/layout.tsx) · api-jobs-auftraege (app/api/admin/jobs) · feat-arbeitsplatz-modell-redesign (MEM:arbeitsplatz-modell-konzept-2026-09-02.md)
Offene Fragen der Seite:
Der Anmeldebildschirm verspricht acht Stunden Sitzungsdauer. Das stimmt nur für den alten Anmeldeweg; eine Anmeldung mit echtem Benutzerkonto hält sieben Tage. Der Text ist damit für die meisten Anmeldungen falsch und gehört korrigiert.
Ob der alte Anmeldeweg über die Zugangsdaten der Server-Einrichtung in der laufenden Werkstatt noch aktiv ist, sagt keine der gelesenen Quellen.
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/daten-recht-sicherheit/sec-admin-login.md).