Die Master-Password-Policy ist eine Tenant-weite Vorgabe, die festlegt, wie stark die Master-Passwörter aller Tresor-User sein müssen. Sie greift jedes Mal, wenn ein:e User ein Master-Password setzt oder ändert — sie schreibt sie also nicht rückwirkend auf bereits gesetzte Passwörter um.
Nur Admins dürfen die Policy konfigurieren.
Die Policy hat vier Stellschrauben:
Frei wählbar zwischen 8 und 64 Zeichen. Default: 12. Die Plattform empfiehlt deutlich mehr — siehe Empfehlung weiter unten.
Vier Kategorien, jede einzeln aktivierbar:
Pro aktivierter Kategorie muss das Passwort mindestens ein Zeichen dieser Klasse enthalten. Komplexitäts-Regeln werden client-seitig validiert (UI verhindert Speichern) und server-seitig gegen-validiert (Schutz vor manipulierten Clients).
Optional. Wenn aktiviert: Master-Password verfällt nach X Tagen, der:die User muss beim nächsten Login ein neues setzen. Wählbar 30 / 60 / 90 / 180 / 365 Tage oder kein Ablauf. Default: kein Ablauf.
Wenn maximales Alter aktiv ist, kann zusätzlich konfiguriert werden, dass die letzten N Passwörter nicht erneut gesetzt werden dürfen. Wählbar 0-10. Implementiert via gesalzene Hashes der historischen Passwörter — die Klartext-Werte werden niemals gespeichert.
Ausschließlich Tenant-Admins. Pfad in der Plattform: Einstellungen → Tools → Zugangsdaten-Tresor → Sicherheit → Master-Password-Policy.
Jede Policy-Änderung erzeugt einen Audit-Log-Eintrag (Aktion policy.change) mit altem und neuem Stand.
Eine Verschärfung der Policy (z.B. Mindestlänge von 12 auf 16 anheben) wirkt ab dem Zeitpunkt für alle neu gesetzten Passwörter. Bereits aktive Passwörter, die der neuen Regel nicht entsprechen, bleiben funktional, bis sie zum nächsten Mal geändert werden. Der Admin kann optional eine Re-Set-Aufforderung für alle User auslösen, die beim nächsten Login das Master-Password neu setzen müssen.
Eine Lockerung der Policy (z.B. Sonderzeichen-Pflicht abschalten) ist möglich, aber im Audit-Log nachvollziehbar dokumentiert. Wir empfehlen, dies nur mit dokumentierter Begründung zu tun.
Die Policy regelt Master-Passwörter, nicht die Inhalte des Tresors. Bestehende Einträge im Tresor sind von einer Policy-Änderung unberührt. Wer einen schwachen ImmoScout24-Login im Tresor hat, hat ihn nach der Policy-Verschärfung weiterhin — die Plattform kann nicht prüfen, wie stark die im Tresor abgelegten Drittsystem-Passwörter sind.
Was sich ändert: Wenn der:die User das eigene Master-Password ändert, gilt die neue Policy. Wenn ein neues Team-Mitglied das Master-Password setzt, gilt die neue Policy.
Wir empfehlen folgendes Profil für Makler-Tenants:
| Parameter | Empfohlener Wert | Begründung |
|---|---|---|
| Mindestlänge | 16 Zeichen | Aktueller BSI- und NIST-Standard für Master-Passwörter. Lange Passphrasen schlagen Komplexität. |
| Großbuchstaben erforderlich | Aus | Erzwungene Komplexität führt zu vorhersehbaren Mustern (Passwort1!). Länge ist wichtiger. |
| Kleinbuchstaben erforderlich | Aus | Wie oben. |
| Ziffern erforderlich | Aus | Wie oben. |
| Sonderzeichen erforderlich | Aus | Wie oben. |
| Maximales Alter | Kein Ablauf | Erzwungene Rotation senkt nachweisbar die Passwort-Qualität. Bei Verdacht auf Kompromittierung: ad-hoc-Reset, nicht zeitgesteuert. |
| Wiederverwendungs-Sperre | Nicht relevant (kein Ablauf) | — |
Hintergrund: Sowohl das BSI in der Technischen Richtlinie BSI-CS 116 als auch das NIST SP 800-63B sind in den letzten Jahren von "kompliziert, oft wechseln" auf "lang, selten wechseln" umgeschwenkt. Der Grund: erzwungene Komplexität verursacht in der Praxis Workarounds (Klebezettel, vorhersehbare Muster), die die Sicherheit faktisch senken. Eine 16-Zeichen-Passphrase wie kornblume-blau-kaffee-7 ist deutlich sicherer als P4ssw0rt!.
Wer aus regulatorischen Gründen (z.B. Konzern-Compliance, Mutterhaus mit ISO-27001) Komplexität erzwingen muss, kann sie aktivieren — die Plattform unterstützt beide Modelle.
Wir empfehlen, die Policy vor dem Einladen des Teams zu setzen. Wenn das Team bereits Passwörter gesetzt hat und die Policy nachträglich verschärft wird, ergibt sich ein Mismatch zwischen alten und neuen User-Passwörtern. Im Tagesgeschäft führt das zu wiederholten Verwirrungen wenn jemand das Passwort ändert und plötzlich strengere Regeln gelten als bei der Erst-Vergabe.
Erstmal Policy, dann Team — gleicher Reihenfolgen-Tipp wie im Schnellstart.
