← Zurück zu News 13.10.2026

Wer den Passwortwechsel abschafft, muss Leaks erkennen

Viele Häuser haben den Passwortwechsel alle 90 Tage abgeschafft, mit dem BSI auf ihrer Seite. Der IT-Grundschutz knüpft das aber an eine Bedingung: Wer nicht mehr nach Kalender wechseln lässt, muss erkennen, wenn ein Passwort kompromittiert ist. Woher diese Erkenntnis kommen kann, und was danach passieren muss.

Der Passwortwechsel alle 90 Tage ist in vielen Häusern abgeschafft, und das zu Recht. Wer alle drei Monate ein neues Passwort erfinden muss, hängt eine Ziffer an das alte oder schreibt es auf. Das BSI sieht das genauso. Nur steht im selben Absatz ein zweiter Satz, der bei der Abschaffung oft fehlt.

Was der Grundschutz verlangt

Die Basis-Anforderung ORP.4.A23 im Baustein Identitäts- und Berechtigungsmanagement sagt zunächst, was viele hören wollen:

„Reine zeitgesteuerte Wechsel SOLLTEN vermieden werden.“

Und direkt danach:

„Es MÜSSEN Maßnahmen ergriffen werden, um die Kompromittierung von Passwörtern zu erkennen.“

Erst wenn das nicht möglich ist, soll laut Anforderung geprüft werden, ob man die Nachteile des zeitgesteuerten Wechsels doch in Kauf nimmt. Die Reihenfolge ist also: erkennen statt wechseln, und wechseln nur, wo man nicht erkennen kann. Was nach der Erkennung passiert, regelt ORP.4.A8:

„Ein Passwort MUSS gewechselt werden, wenn es unautorisierten Personen bekannt geworden ist oder der Verdacht dazu besteht.“

Wer den Kalenderwechsel abgeschafft hat, ohne eine Erkennung einzuführen, hat also nicht modernisiert, sondern eine Basis-Anforderung gestrichen.

Woher die Erkenntnis kommt

Ein Passwort wird selten im eigenen Netz kompromittiert. Es geht verloren, wo die Beschäftigten es außerhalb benutzen, und taucht dann an drei Arten von Orten auf:

Bekannte Datenpannen. Ein Dienst, bei dem jemand dieselbe Adresse und womöglich dasselbe Passwort benutzt hat, wird gehackt. Die Zugangsdaten landen in Sammlungen, die später öffentlich bekannt werden.
Stealer-Logs. Schadsoftware auf einem privaten Rechner liest alles aus, was im Browser gespeichert ist: Passwörter, aber auch Sitzungs-Cookies. Mit einem gültigen Sitzungs-Cookie braucht der Angreifer weder das Passwort noch den zweiten Faktor.
Foren, Telegram-Kanäle, Paste-Dienste. Dort werden Zugänge gehandelt oder als Probe veröffentlicht, oft bevor irgendjemand von einer Panne weiß.

Von außen sieht man auf diese Orte nur über Anbieter, die sie systematisch auswerten. Selbst in Foren zu suchen, ist weder ein Prozess noch eine gute Idee.

Was ein Treffer auslösen muss

Ein Treffer ist der Verdacht aus ORP.4.A8, und damit ist der Wechsel Pflicht. Aber bei einem Stealer-Log reicht er nicht: Solange die alte Sitzung gültig ist, hilft das neue Passwort wenig. Also gehören zum Treffer mindestens drei Schritte: Passwort wechseln, bestehende Sitzungen beenden und nachsehen, ob der Zugang in der Zwischenzeit benutzt wurde. Ob daraus ein meldepflichtiger Vorfall wird, entscheidet sich an dieser dritten Frage. Wie man mit dem verwandten Fall umgeht, dass ein Lieferant auf einer Erpresserseite steht, stand in Wenn der Lieferant auf der Leak-Site steht.

Wie isidaten das abbildet

Die Dunkelnetz-Beobachtung fragt Anbieter wie Intelligence X und Flare über deren Schnittstellen ab, mit einem Vertrag beim jeweiligen Anbieter und ohne selbst das Tor-Netz aufzurufen. Gesucht wird nach den Domains und Organisationsnamen aus dem Bestand, nach namentlich genannten Personen nur mit ausdrücklicher Freigabe. Vom Passwort speichert isidaten nichts, nur ob der Fund eines enthielt; Personen werden über den SHA-256-Hash der E-Mail-Adresse zugeordnet. Zu jedem Treffer schlägt isidaten die Reaktion vor, etwa einen Vorfall und eine Reset-Aufgabe an die Verantwortlichen. Automatisch geschieht das nur, wenn es je Reaktion eingeschaltet ist, ab Werk ist es aus. Das Passwort selbst setzt isidaten nicht zurück; das bleibt im Verzeichnisdienst und bei den Menschen, die dafür zuständig sind. Bekannte Datenpannen kann zusätzlich die Leak-Prüfung im Angriffsflächen-Management abfragen.