Sitzungstoken
Passwork verwendet ein tokenbasiertes Authentifizierungsmodell mit Access Token / Refresh Token-Paar.
Übersicht des Token-Systems
| Token | Zweck | Lebensdauer |
|---|---|---|
| Access Token | API-Anfragenauthentifizierung | ~2,8 Stunden |
| Refresh Token | Erneuerung des Access Token | 36 Stunden |
Warum kein JWT?
Passwork-Token sind zufällige Zeichenfolgen, kein JWT. Für einen Passwortmanager bietet dieser Ansatz höhere Sicherheit:
| Eigenschaft | Passwork-Token | JWT |
|---|---|---|
| Format | Zufällige Base64-Zeichenfolge | JSON mit Signatur |
| Informationen im Token | Keine | Payload mit Daten |
| Validierung | Datenbankabfrage | Signaturüberprüfung |
| Token-Widerruf | Sofort (DB-Löschung) | Erfordert Blacklist |
Sicherheitsvorteile:
-
Sofortiger Sitzungswiderruf. Bei Verdacht auf Kompromittierung kann der Administrator oder Benutzer jede Sitzung sofort beenden — das Token wird aus der Datenbank gelöscht und wird sofort ungültig. JWT funktioniert bis zum Ablauf weiter.
-
Vollständige Sitzungskontrolle. Alle aktiven Sitzungen werden auf dem Server gespeichert, was die Verfolgung von Geräten, IP-Adressen und der letzten Aktivitätszeit ermöglicht. Der Administrator hat ein vollständiges Bild und kann den Zugriff verwalten.
-
Keine sensiblen Daten im Token. JWT enthält einen Payload mit Benutzerinformationen, der gelesen werden kann (Base64 ist keine Verschlüsselung). Passwork-Token sind einfach zufällige Identifikatoren ohne jegliche Information.
-
Resistenz gegen Schlüsselkompromittierung. Wenn der geheime JWT-Schlüssel durchsickert, kann ein Angreifer gültige Token für jeden Benutzer erstellen. Bei Sitzungstoken existiert dieser Angriffsvektor nicht.
-
Kein Signierschlüssel. JWT erfordert die Speicherung eines privaten Schlüssels auf dem Server für die Token-Signierung — ein weiteres Geheimnis, das geschützt, rotiert und kontrolliert werden muss. Passwork-Sitzungstoken sind einfach zufällige Zeichenfolgen, für deren Generierung keine geheimen Schlüssel benötigt werden.
Access Token
Eigenschaften
| Parameter | Wert |
|---|---|
| Länge | 256 Bit |
| Format | Base64 |
| Zeichenfolgenlänge | ~44 Zeichen |
| Entropie | 256 Bit |
| Standardlebensdauer | 10.000 Sekunden (~2,8 Stunden) |
Generierung
Das Access Token wird mit einem kryptografisch sicheren Zufallszahlengenerator generiert:
token = base64(random_bytes(32))
Validierung
Bei jeder Anfrage führt der Server folgende Schritte durch:
- Extrahiert das Token (aus Cookie oder Header, je nach Modus)
- Sucht das Token in der Datenbank
- Überprüft die Lebensdauer
- Verknüpft die Anfrage mit dem Benutzer
Token-Übertragungsmodi
Passwork verwendet zwei Access-Token-Übertragungsmodi, abhängig vom Client-Typ:
Browser-Modus (Webanwendung)
Für die Webanwendung wird das Access Token über HttpOnly Cookie übertragen:
| Parameter | Wert |
|---|---|
| HttpOnly | Ja — für JavaScript unzugänglich (XSS-Schutz) |
| Secure | Ja — nur HTTPS |
| SameSite | Strict — CSRF-Schutz |
In diesem Modus fügt der Browser automatisch das Cookie an jede Anfrage an. Das Access Token wird bei der Authentifizierung nicht im Antworttext zurückgegeben — nur im Set-Cookie-Header.
API-Modus (Desktop, Erweiterung, Mobil)
Für API-Clients wird das Access Token im Authorization-Header übertragen:
Authorization: Bearer {access_token}
In diesem Modus wird das Access Token bei der Authentifizierung im Antworttext zurückgegeben, und der Client verwaltet die Speicherung selbstständig.
Modusvergleich
| Parameter | Browser-Modus | API-Modus |
|---|---|---|
| Clients | Webanwendung | Desktop, Erweiterung, Mobil |
| Token-Übertragung | HttpOnly Cookie | Authorization-Header |
| XSS-Schutz | ✓ (HttpOnly) | Abhängig vom Client |
| Token-Verwaltung | Browser (automatisch) | Client (manuell) |
Refresh Token
Eigenschaften
| Parameter | Wert |
|---|---|
| Länge | 256 Bit |
| Format | Base64 |
| Zeichenfolgenlänge | ~44 Zeichen |
| Entropie | 256 Bit |
| Standardlebensdauer | 129.600 Sekunden (36 Stunden) |
Zweck
Das Refresh Token wird verwendet, um ein neues Access Token ohne erneute Authentifizierung zu erhalten. Mehr zum Erneuerungsprozess im Abschnitt Token-Rotation.
Lebensdauer-Konfiguration
Nach Benutzerrollen
Die Token-Lebensdauer wird auf Benutzerrollenebene konfiguriert:
| Einstellung | Standardwert |
|---|---|
| Access-Token-Lebensdauer | 10.000 Sek. (~2,8 Stunden) |
| Refresh-Token-Lebensdauer | 129.600 Sek. (36 Stunden) |
Konfigurationsbeispiele
| Szenario | Access TTL | Refresh TTL |
|---|---|---|
| Standardbenutzer | 10.000 Sek. | 129.600 Sek. |
| Hohe Sicherheit | 1.800 Sek. (30 Min.) | 14.400 Sek. (4 Stunden) |
| Komfort | 28.800 Sek. (8 Stunden) | 604.800 Sek. (7 Tage) |
Sitzungslebenszyklus
Vollständiger Lebenszyklus
T=0: Authentifizierung. Benutzer gibt Anmeldedaten ein. Server erstellt Access Token (TTL: 2,8 Stunden) und Refresh Token (TTL: 36 Stunden).
T=2,8h: Access Token abgelaufen. Client sendet Refresh Token. Server stellt neue Token aus. Altes Refresh Token wird ungültig.
T=36h: Refresh Token abgelaufen. Erneute Authentifizierung erforderlich. Benutzer gibt Anmeldedaten erneut ein.
Alternatives Szenario — Abmeldung. Benutzer klickt auf „Abmelden". Beide Token werden ungültig. Sitzung beendet.
Token-Ungültigmachung
Alle Sitzungstoken werden ungültig bei:
- Benutzerabmeldung
- Änderung des Masterpassworts
- Administrator-Reset des Masterpassworts
Token-Rotation
Standardmodus (Anwendungen)
Für Webanwendung, Browsererweiterung, Mobile und Desktop-Apps gilt eine strikte Token-Rotationsrichtlinie.
Bei der Sitzungserneuerung sendet der Client Access Token und Refresh Token gleichzeitig und erhält ein neues Token-Paar als Antwort. Dies ermöglicht eine kontinuierliche Rotation beider Token und verhindert die Wiederverwendung gestohlener Token.
Automatisierungsmodus (API)
Für DevOps-Aufgaben und Automatisierung ist strikte Rotation oft unpraktisch. Daher steht für über API-Token-Generierung erstellte Sitzungen ein alternativer Modus zur Verfügung:
- Nur Erneuerung des Access Token ohne Änderung des Refresh Token
- Separate Refresh-Token-Erneuerung bei Bedarf
Dies ermöglicht die Verwendung langlebiger Refresh Token in Skripten und CI/CD-Pipelines.
Token-Sicherheit
Schutz vor Abfangen
| Bedrohung | Schutz |
|---|---|
| Netzwerkabfangen | HTTPS/TLS erforderlich |
| XSS-Angriff | HttpOnly Cookies (Browser-Modus) |
| CSRF | CSRF Token + SameSite Cookies |
CSRF Token
Zweck
Das CSRF Token schützt vor Cross-Site-Request-Forgery-Angriffen. Erforderlich für alle ändernden Operationen.
Eigenschaften
| Parameter | Wert |
|---|---|
| Größe | 256 Bit |
| Format | Hexadezimal (64 Zeichen) |
| Entropie | 256 Bit |
| Generator | Kryptografisch sicher |
Verwendung
Das CSRF Token wird im Header jeder Anfrage übertragen:
X-CSRF-Token: {csrf_token}
Anforderungen nach Client-Typ
| Client-Typ | CSRF Token |
|---|---|
| Webanwendung (Browser-Modus) | ✓ Erforderlich (automatisch generiert und validiert) |
| Browsererweiterung | Optional (auf Client-Anfrage) |
| Mobile Anwendung | Optional (auf Client-Anfrage) |
| API | — (nicht verwendet) |
Cookie Sign
Zweck
Optionale zusätzliche Schutzfunktion für den Browser-Modus. Bindet die Sitzung an den Client-Kontext und schützt vor Cookie-Diebstahl und Session-Hijacking.
Funktionsweise
Bei Aktivierung berechnet der Server eine Signatur basierend auf:
- Client-IP-Adresse
- Browser User-Agent
- Sitzungskennung
- Geheimem Schlüssel (60 Zeichen, ~357 Bit Entropie)
Die Signatur wird nach folgender Formel berechnet:
cookieSign = HMAC-SHA512(IP + UserAgent + SessionID, secret)
Die Signatur wird in einem separaten HttpOnly Cookie gespeichert und bei jeder Anfrage überprüft.
Angriffsschutz
| Angriff | Schutz |
|---|---|
| Session Hijacking | Gestohlenes Cookie funktioniert nicht von einer anderen IP |
| Cookie-Diebstahl | Cookie nutzlos ohne übereinstimmende IP + User-Agent |
Einschränkungen
- IP-Wechsel (VPN, mobiles Netzwerk) erfordert erneute Authentifizierung
- Browser-Update kann den User-Agent ändern
Aktivierung
Die Funktion wird vom Administrator in den Systemeinstellungen aktiviert. Standardmäßig deaktiviert für Kompatibilität mit Benutzern mit dynamischer IP.
Client-Typen
Passwork unterscheidet vier Client-Typen mit unterschiedlichen Sicherheitsmechanismen:
| Funktion | Web | Browsererweiterung | Mobil | API |
|---|---|---|---|---|
| Token-Übertragungsmodus | Browser-Modus | API-Modus | API-Modus | API-Modus |
| Access Token | Cookie | Header | Header | Header |
| CSRF Token | ✓ Erforderlich | Optional | Optional | — |
| Cookie Sign | Optional | — | — | — |
| PIN-Code | — | ✓ Unterstützt | — | — |
Browsererweiterung — einziger Client-Typ mit Unterstützung für Server-seitige PIN-Code-Prüfung. Der PIN wird auf dem Server überprüft, was ein temporäres Fenster für die API-Nutzung öffnet. Nach Zeitablauf wird die Sitzung gesperrt, bis der PIN erneut eingegeben wird. Bei mehreren falschen Versuchen beendet der Server die Sitzung sofort. Dies schützt vor Token-Diebstahl — selbst bei Token-Kompromittierung kann ein Angreifer die API nicht ohne Kenntnis des PINs verwenden.
HTTP-Header
Authentifizierungs-Header
| Header | Beschreibung | Modus |
|---|---|---|
Authorization | Access Token (Bearer {token}) | API-Modus |
Cookie | Access Token (automatisch) | Browser-Modus |
X-CSRF-Token | CSRF-Schutz | Alle Modi |
X-Master-Key-Hash | Masterschlüssel-Hash | Bei Bedarf |
Client-seitige Token-Speicherung
Jeder Client-Typ implementiert eine sichere Token-Speicherung entsprechend den Plattformmöglichkeiten:
- Webanwendung — Access Token wird in HttpOnly Cookie gespeichert, für JavaScript unzugänglich (XSS-Schutz)
- Desktop- und Mobile Apps — Token werden im sicheren OS-Speicher mit eingeschränktem Zugriff gespeichert
- Browsererweiterung — isolierter Browser-Speicher wird verwendet, von Webseiten nicht zugänglich
Mehrere Sitzungen
Parallele Sitzungen
Passwork unterstützt mehrere gleichzeitige Sitzungen:
- Benutzer kann auf mehreren Geräten gleichzeitig authentifiziert sein
- Jedes Gerät hat sein eigenes Token-Paar
- Abmeldung auf einem Gerät beeinflusst die anderen nicht
Sitzungsverwaltung
Der Benutzer kann:
- Liste aktiver Sitzungen anzeigen
- Bestimmte Sitzung beenden
- Alle Sitzungen beenden (außer der aktuellen)
Der Administrator kann:
- Alle Benutzersitzungen erzwungen beenden
Konfigurationsempfehlungen
Hohe Sicherheit
| Parameter | Wert |
|---|---|
| Access Token | 30 Minuten |
| Refresh Token | 4 Stunden |
- Häufige erneute Authentifizierung
- Kurzes Angriffsfenster
- Geeignet für kritische Systeme
Balance zwischen Sicherheit und Komfort (Standard)
| Parameter | Wert |
|---|---|
| Access Token | ~2,8 Stunden |
| Refresh Token | 36 Stunden |
- Arbeitstag ohne erneute Authentifizierung
- Refresh Token für ~1,5 Arbeitstage
- Geeignet für die meisten Organisationen
Maximaler Komfort
| Parameter | Wert |
|---|---|
| Access Token | 8 Stunden |
| Refresh Token | 7 Tage |
- Authentifizierung einmal pro Woche
- Geeignet für Szenarien mit niedrigem Risiko
- Nicht empfohlen für kritische Daten