Authentifizierung und Masterschlüssel
Die Authentifizierung in Passwork besteht aus zwei Stufen: Basisauthentifizierung und Masterpasswort-Überprüfung (wenn CSE aktiviert ist).
Zweistufige Authentifizierung
| Stufe | Zweck | Ausführungsort |
|---|---|---|
| Basisauthentifizierung | Überprüfung der Anmeldedaten | Server |
| Masterpasswort-Überprüfung | Zugang zu verschlüsselten Daten | Client + Server |
Stufe 1: Basisauthentifizierung
Lokale Authentifizierung
- Benutzer gibt Benutzername und Passwort ein
- Server überprüft das Passwort (PBKDF2, 600.000 Iterationen, SHA-512)
- Bei Erfolg werden Access Token und Refresh Token ausgestellt
- Client speichert Token für nachfolgende Anfragen
Server-Passwort-Hashing-Parameter:
| Parameter | Wert |
|---|---|
| Algorithmus | PBKDF2 |
| Hashfunktion | SHA-512 |
| Iterationen | 600.000 |
| Schlüssellänge | 512 Bit |
SSO / LDAP-Authentifizierung
Mit SSO oder LDAP:
- Benutzer wird zum externen Anbieter weitergeleitet
- Nach erfolgreicher Authentifizierung kehrt er zu Passwork zurück
- System erstellt eine Sitzung und stellt Token aus
- Falls CSE aktiviert ist — Eingabe des Masterpassworts wird angefordert
Stufe 2: Masterpasswort-Überprüfung
Bei aktivierter Client-seitiger Verschlüsselung ist nach der Basisauthentifizierung die Eingabe des Masterpassworts erforderlich.
Parameter abrufen
Der Client fordert Parameter vom Server zur Berechnung des Masterschlüssels an:
- Salt — einzigartig pro Benutzer
- Iterationsanzahl — 300.000
- Algorithmustyp — PBKDF2
Masterschlüssel berechnen
Die Schlüsselableitung wird auf dem Client durchgeführt:
| Parameter | Wert |
|---|---|
| Algorithmus | PBKDF2 |
| Hashfunktion | SHA-256 |
| Iterationen | 300.000 |
| Schlüssellänge | 512 Bit |
| Eingabe | Masterpasswort + Salt |
| Ausgabe | Masterschlüssel (Base64) |
Überprüfungshash berechnen
Zur Bestätigung der korrekten Eingabe wird ein Hash des Masterschlüssels berechnet:
| Parameter | Wert |
|---|---|
| Algorithmus | SHA-256 |
| Eingabe | Masterschlüssel (512 Bit) |
| Ausgabe | Hash (256 Bit, Hex-Zeichenfolge) |
Serverüberprüfung
Der Server vergleicht den empfangenen Hash mit dem gespeicherten Wert.
Warum einfacher Hash-Vergleich?
- Der Hash wird auf dem Client aus einem kryptografisch starken 512-Bit-Schlüssel berechnet
- Der Server kennt den ursprünglichen Masterschlüssel nicht
- Zusätzliches Server-seitiges Hashing bringt in diesem Zero-Knowledge-Modell keine zusätzliche Sicherheit
Vollständige Authentifizierungssequenz
Phase 1 — Basisauthentifizierung:
- Benutzer gibt Benutzername und Passwort ein
- Server überprüft Anmeldedaten (PBKDF2, SHA-512, 600K Iterationen)
- Server gibt Zugriffstoken und CSE-Flag zurück
Phase 2 — Masterpasswort (falls CSE aktiviert):
- Client fordert PBKDF2-Parameter an (Salt, Iterationen)
- Benutzer gibt Masterpasswort ein
- Client berechnet Masterschlüssel: PBKDF2(Passwort, Salt, 300K, SHA-256) → 512 Bit
- Client berechnet Hash: SHA-256(Masterschlüssel) → 256 Bit
- Client sendet Hash an Server
- Server vergleicht Hashes
- Bei Erfolg gibt der Server den verschlüsselten privaten RSA-Schlüssel zurück
Phase 3 — Schlüsselentschlüsselung:
- Client entschlüsselt privaten RSA-Schlüssel mit Masterschlüssel (AES-256-CBC)
- Client ist bereit, mit verschlüsselten Daten zu arbeiten
Zero-Knowledge-Prinzip
Das Masterpasswort verlässt niemals den Client. Der Server sieht nur den Masterschlüssel-Hash. Der private RSA-Schlüssel wird nur in verschlüsselter Form übertragen.
Salt-Parameter
| Parameter | Wert |
|---|---|
| Länge | 20 Zeichen |
| Alphabet | A-Z, a-z, 0-9, @, ! (64 Zeichen) |
| Entropie | ~120 Bit |
| Generierung | Server, bei Erstellung/Änderung des Masterpassworts |
| Speicherung | Im Benutzerprofil auf dem Server |
Salt-Eigenschaften:
- Jeder Benutzer hat ein einzigartiges Salt
- Bei Änderung des Masterpassworts wird ein neues Salt generiert
- Salt ist nicht geheim, stellt aber die Hash-Einzigartigkeit sicher
Authentifizierungsszenarien
Erste Anmeldung (Masterpasswort festlegen)
- Benutzer schließt die Basisauthentifizierung ab
- System stellt fest, dass kein Masterpasswort gesetzt ist
- Server generiert neues Salt
- Benutzer gibt neues Masterpasswort ein
- Client führt kryptografische Operationen durch:
- Berechnet Masterschlüssel (PBKDF2)
- Generiert RSA-Schlüsselpaar (2048 Bit)
- Verschlüsselt privaten RSA-Schlüssel mit Masterschlüssel (AES-256-CBC)
- Berechnet Masterschlüssel-Hash (SHA-256)
- Client sendet an Server:
- Öffentlichen RSA-Schlüssel (offen)
- Verschlüsselten privaten RSA-Schlüssel
- Masterschlüssel-Hash
Nachfolgende Anmeldung
- Basisauthentifizierung
- PBKDF2-Parameter abrufen (Salt, Iterationen)
- Masterpasswort eingeben
- Masterschlüssel und Hash berechnen
- Hash auf dem Server überprüfen
- Privaten RSA-Schlüssel entschlüsseln (AES-256-CBC)
Masterpasswort ändern
- Benutzer gibt aktuelles Masterpasswort ein
- Korrektheitsprüfung (Hash-Vergleich)
- Neues Masterpasswort eingeben
- Neues Salt wird auf dem Server generiert
- Masterschlüssel und Hash neu berechnen
- Privaten RSA-Schlüssel mit altem Masterschlüssel entschlüsseln
- Privaten RSA-Schlüssel mit neuem Masterschlüssel verschlüsseln (AES-256-CBC)
- Neue Daten auf dem Server speichern
Masterpasswort-Reset (durch Administrator)
Datenverlust
Wenn ein Administrator das Masterpasswort zurücksetzt:
- Ein neues RSA-Schlüsselpaar wird generiert
- Der Benutzer verliert den Zugang zu zuvor verschlüsselten Daten
- Die erneute Gewährung von Tresorzugang ist erforderlich
- Administrator initiiert den Reset
- Kryptografische Daten des Benutzers werden gelöscht
- Benutzer legt ein neues Masterpasswort fest
- Neue RSA-Schlüssel werden generiert
- Tresoradministratoren müssen den Zugang erneut gewähren
Bedrohungsmodell und Schutz
Schutz des Masterpassworts
| Bedrohung | Schutz |
|---|---|
| Abfangen bei der Eingabe | Masterpasswort wird nur im Browser verarbeitet |
| Abfangen bei der Übertragung | Nur Masterschlüssel-Hash wird an den Server gesendet |
| Brute-Force-Angriff | PBKDF2 mit 300.000 Iterationen |
| Rainbow-Tabellen | Einzigartiges Salt pro Benutzer |
| Serverkompromittierung | Server speichert weder Masterpasswort noch Masterschlüssel |
Schutz des Masterschlüssel-Hashs
| Bedrohung | Schutz |
|---|---|
| Hash-Leck | Hash wird aus 512-Bit-Schlüssel berechnet (nicht aus Passwort) |
| Hash-basiertes Erraten | PBKDF2 macht jeden Versuch rechenintensiv |
| Passwortwiederherstellung | Zuerst muss der Schlüssel, dann das Passwort erraten werden |
Sitzungsschutz
| Parameter | Access Token | Refresh Token |
|---|---|---|
| Lebensdauer | ~2,8 Stunden | 36 Stunden |
| Zweck | Anfragenauthentifizierung | Access-Token-Erneuerung |
| Speicherung | Sicherer Browser-Speicher | Sicherer Browser-Speicher |
Fehlerbehandlung
Falsches Masterpasswort
- Berechneter Hash stimmt nicht mit gespeichertem Wert überein
- Server gibt Fehler zurück
- Client fordert zur erneuten Eingabe auf
- Versuchslimits möglich (vom Administrator konfigurierbar)
Fehlende PBKDF2-Parameter
Wenn Parameter nicht gefunden werden — Masterpasswort ist nicht gesetzt, Ersteinrichtung erforderlich.
RSA-Schlüssel kann nicht entschlüsselt werden
Wenn die Entschlüsselung des privaten RSA-Schlüssels fehlschlägt — falsches Masterpasswort oder beschädigte Daten.
Kryptografische Zusammenfassung
| Operation | Algorithmus | Parameter |
|---|---|---|
| Passwort-Hashing (Server) | PBKDF2-SHA512 | 600.000 Iterationen |
| Masterschlüssel-Ableitung (Client) | PBKDF2-SHA256 | 300.000 Iterationen, 512 Bit |
| Überprüfungshash | SHA-256 | 256 Bit |
| RSA-Schlüssel-Verschlüsselung | AES-256-CBC | Masterschlüssel |
| RSA-Schlüssel-Generierung | RSA-OAEP | 2048 Bit, SHA-256 |