Wenn das Administratorpasswort noch als SHA-256 gespeichert ist: Warum das GPU-Offline-Cracking Sie zuerst vor der Firewall aussperrt

Am 6. Oktober 2026 haben FBI und US Secret Service die gemeinsame Meldung FortiBleed veröffentlicht. Auf öffentlich erreichbaren FortiGate-Firewalls und SSL-VPNs werden wiederverwendete Passwörter und ein zurückgebliebenes SHA-256-Verfahren für Administratorzugänge massenhaft geprüft und offline geknackt. Manche Betreiber kommen nicht mehr hinein, weil das Passwort des ursprünglichen Kontos geändert oder das Konto gelöscht wurde. Ein Upgrade auf eine FortiOS-Version mit PBKDF2 ersetzt den alten Hash nicht, bevor sich dieser Administrator angemeldet hat.

Zuerst die Trennung: Ein zurückgebliebenes SHA-256 beantwortet, ob jede Vermutung billig wird, sobald der Hash das Gerät verlassen hat. Wiederverwendung beantwortet, dass gar nicht geraten werden muss. Vor der Firewall zu stehen heißt, dass nach dem Eindringen jemand das ursprüngliche Konto angefasst hat. Der Algorithmus verriegelt die Tür nicht von selbst. Nach dem Wechsel auf ein FortiOS mit PBKDF2 wird der alte Hash erst ersetzt, wenn sich der betreffende Administrator erfolgreich anmeldet oder ein Super-Admin das Passwort neu setzt. Damit ein späteres Downgrade noch möglich bleibt, liegt das alte SHA-256 standardmäßig weiter in einem verborgenen Feld.

Die Suchintention in einem Satz

Wer nach FortiBleed, nach einem ausgesperrten Firewall-Administrator oder nach „SHA-256 speichert Passwörter“ sucht, hat drei Vorgänge in derselben Schlagzeile. Erstens nehmen Angreifer Passwörter aus älteren Leaks oder aus Infostealer-Logs und melden sich damit an FortiGate-SSL-VPNs an, die noch im öffentlichen Netz stehen. Zweitens lässt sich das Material, das der Hersteller als zurückgebliebenes SHA-256 für Administratorpasswörter bezeichnet, nach dem Abzug mit einem GPU-Cluster offline durchprobieren. Drittens legt die Gegenseite danach neue Konten an und ändert oder löscht die bisherigen Administratoren. Die legitimen Personen öffnen das Portal nicht mehr.

Dieser Text ist für Betrieb, das Firewalls oder VPN-Konten noch selbst verwaltet, und für Kolleginnen und Kollegen, die den Auftrag haben, heute Nacht alle Administratorpasswörter zu wechseln. Er ersetzt nicht die Bedienung des Passwort-Generators und behauptet nicht, dass Passwortstärke prüfen abfragt, ob dieses Gerät in FortiBleed vorkommt. Mitnehmen sollten Sie: welchen Ausfall ein schneller Hash, eine langsame Schlüsselableitung, Passwort-Wiederverwendung und ein gelöschtes Konto jeweils abfangen, und welche zwei Markierungen im Konfigurationsbackup Sie auf dem eigenen Rechner nachsehen.

Was die Meldung vom 6. Oktober tatsächlich schreibt

Die gemeinsame Meldung von FBI und US Secret Service vom 6. Oktober 2026 (Aktenzeichen JCSA-20261006-01, gekennzeichnet als TLP:CLEAR) nennt die Operation FortiBleed. Ziel sind Fortinet-FortiGate-Firewalls und SSL-VPN-Gateways, die aus dem Internet erreichbar sind. Die Meldung zitiert eine Prüfung von SOCRadar: mehr als 86.644 Geräte in 194 Ländern. Sie schreibt, der Angriff nutze wiederverwendete oder bereits geleakte Passwörter sowie eine zurückgebliebene SHA-256-Speicherung, um Authentifizierungsmaterial in Menge abzuziehen und zu knacken. Der erste Befund: Angreifer scannen weiter öffentlich exponierte Fortinet-Firewalls mit zuvor erlangten Passwörtern.

Dieselbe Datei beschreibt, dass ein eigenes Backend-Verzeichnis der Gegenseite zeitweise offen lag und die Werkzeugkette dadurch sichtbar wurde. Nach dem Fund eines FortiGate-SSL-VPN-Portals folgen Credential Stuffing und Password Spraying aus älteren Fortinet-Leak-Beständen und aus Infostealer-Logs. Abgezogene Passwort-Hashes gehen in einen GPU-Cluster, den Hashcat und Hashtopolis verteilen, und werden offline durchprobiert. Treffer werden gefiltert, geprüft und danach als neue Administratorkonten auf der Firewall angelegt. Die Meldung beschreibt die weitere Wirkung als Weiterverkauf des Erstzugangs und schreibt, diese Kette sei an Ransomware-Partner übergeben worden, namentlich INC/Lynx und Payload. Diese Sätze stehen so in der Meldung. Dieser Text hat die Untersuchung nicht selbst wiederholt.

Direkt gegen die Lesart „ein Passwortwechsel schließt den Vorgang“ steht der Abschnitt zur Aussperrung. Nach den ersten Reaktionen finden Organisationen sich ausgesperrt, wenn die Gegenseite das ursprüngliche Konto löscht oder dessen Passwort ändert. Während des Eindringens entstehen Konten, die vorher nicht auf dem Gerät waren. In manchen Fällen dient das Löschen bestehender Konten dazu, den eigenen Zugang der Organisation zu blockieren und sich im Netz weiterzubewegen. Die Meldung schreibt deshalb: Die Bereinigung kann über das übliche Patchen und Zurücksetzen von Passwörtern hinausgehen. Diesen Schritt ordnet sie MITRE ATT&CK T1531 zu, Account Access Removal, also dem gezielten Entfernen des Kontozugangs.

Dieser Text liefert keine Befehle zum Abziehen von Hashes, keine Wörterbücher und keine Cracking-Kommandos. Er übernimmt auch nicht die Adress- und Kontonamenlisten aus der Meldung. Die Listen sind für Verteidiger gedacht, die bereits Logs prüfen. Die Prüfung unten nutzt nur Geräte, die Sie verwalten dürfen, und die öffentliche Herstellerdokumentation. Laden Sie kein offenes Verzeichnis unbekannter Herkunft herunter, um „die Meldung zu prüfen“, und fügen Sie ein Konfigurationsbackup mit Passwort-Hashes nicht in ein Ticket oder ein Chatfenster ein.

Wiederverwendung und Offline-Cracking sind nicht derselbe Weg

Schlagzeilen ziehen „das Passwort war zu schwach“ zu einer einzigen Ursache zusammen. In der Meldung stehen mindestens zwei Wege, deren Fehlbedingung verschieden ist. Credential Stuffing und Password Spraying passieren beim Online-Login. Die Gegenseite schickt Klartext, den sie schon kennt oder gerade ausprobiert. Welchen Algorithmus das Gerät zum Speichern benutzt, betrifft nur den eigenen Vergleich auf dem Gerät. Die Zeichenfolge in der Hand der Gegenseite ändert das nicht. Stimmt sie mit einem noch gültigen VPN- oder Administratorkonto überein, ist die Anmeldung gültig.

Offline-Cracking beginnt, nachdem der Hash bereits kopiert wurde. Die Gegenseite klopft nicht mehr an Ihr Portal. Sie zählt Vermutungen auf eigenen Maschinen auf, macht aus jeder Vermutung einen Hash und vergleicht ihn mit dem kopierten Material. Die Kosten hängen davon ab, wie viel Arbeit das Speicherverfahren pro Vermutung verlangt, und davon, wie groß der Suchraum des Passworts ist. SHA-256 ist ein schneller Hash für Integrität: Dieselbe Eingabe ergibt immer dieselbe Ausgabe, und eine Berechnung reicht. Er eignet sich, um eine Datei zu prüfen. Allein trägt er nicht die Aufgabe, jede Passwortvermutung spürbar zu verteuern. Ein gemieteter GPU-Cluster parallelisiert genau diese eine, fertige Rechnung. Hashtopolis verteilt in der Meldung Cracking-Aufträge auf mehrere Maschinen. Es ist kein neuer Verschlüsselungsalgorithmus.

Weg Was die Gegenseite hat Nachdem die Speicherung PBKDF2 ist
Credential Stuffing / Password Spraying Klartext oder eine kurze Liste häufiger Passwörter Klartext meldet sich weiter direkt an. Eine langsame Ableitung hält ein bekanntes Passwort nicht auf
Offline-Cracking Einen vom Gerät kopierten Passwort-Hash Jede Vermutung wird teurer. Kurze und wiederverwendete Passwörter bleiben erratbar
Aussperrung Eine bereits angemeldete Verwaltungssitzung Der Algorithmuswechsel hindert niemanden daran, das ursprüngliche Konto zu ändern oder zu löschen

Die dritte Zeile soll eine häufige Lesart stoppen: „Wir nutzen jetzt einen langsameren Hash“ wird zu „Administratoren stehen nicht mehr draußen“. Die Aussperrung passiert, nachdem die Anmeldung schon durch ist. Sie hängt daran, dass die Gegenseite die Konfiguration ändern kann. Sie hängt nicht daran, wie schnell SHA-256 rechnet. Umgekehrt deckt ein reines Zurücksetzen der Passwörter, ohne die öffentliche Verwaltungsfläche einzuziehen und ohne phishing-resistente Mehrfaktor-Authentifizierung, nur einen Teil der Liste ab. FBI und Secret Service stellen das Einschränken des Verwaltungszugangs, das Beenden laufender Verwaltungs- und VPN-Sitzungen, das Zurücksetzen der Passwörter, phishing-resistente Mehrfaktor-Authentifizierung, das Prüfen unbekannter Konten und die Bestätigung von PBKDF2 in dieselbe Gruppe von Maßnahmen.

Was SHA-256 und PBKDF2 jeweils belegen

Das OWASP Password Storage Cheat Sheet löst die Passwortspeicherung aus „einmal einen schnellen Hash rechnen“: Es soll eine langsame Schlüsselableitung mit eindeutigem Salt sein, zum Beispiel Argon2id, bcrypt, scrypt oder PBKDF2 mit genug Iterationen. Der Salt sorgt dafür, dass eine vorausberechnete Tabelle nicht von einer Person auf die nächste wandert. Iteration oder ein speicherharter Parameter sorgen dafür, dass jede Vermutung viel Arbeit wiederholt. Beides beantwortet verschiedene Fragen. Nur ein Salt und danach weiterhin ein einziges SHA-256 macht Regenbogentabellen unbrauchbar. Die GPU-Suche über kurze Passwörter bleibt billig. Nur langsam, aber mit einem gemeinsamen Salt für alle, lässt sich eine große Hash-Menge weiter mit einer Tabelle abdecken. Die Meldung schreibt das alte Fortinet-Verfahren nicht als „vollständig ohne Salt“. Dieser Text ergänzt dieses Detail nicht. In den Satz gehört der Vergleich, den der Hersteller später selbst zieht.

Die technische Notiz von Fortinet zum Administrator-Passwort-Hash schreibt: Ab FortiOS 7.2.11, 7.4.8 und 7.6.1 wechselt der Hash, mit dem die Firewall Administratorzugangsdaten in der Konfiguration hält, von SHA256 auf PBKDF2. In der Notiz steht SH2 für SHA256 und PB2 für PBKDF2. Unterhalb dieser Schwellen markiert dieselbe Notiz die Hash-Funktion weiter als SHA256. Die Release Notes zu 7.2.11 beschreiben das neue Verfahren als PBKDF2 mit zufälligem Salt, um die Speicherung lokaler Systemadministrator-Passwörter zu härten. Das ist ein anderer Satz als „auf der Seite steht verschlüsselt“. SHA-256 und PBKDF2 sind hier beides Einweg-Ableitungen. Keines der beiden packt das Passwort mit einem symmetrischen Schlüssel in umkehrbaren Chiffretext. SH2 heißt nicht „auf der Platte liegt Klartext“. PB2 heißt nicht „ein geleakter Klartext ist egal“.

PBKDF2 hat keine weltweit einheitliche Iterationszahl, ab der es „langsam genug“ wäre. Die Herstellerdokumentation veröffentlicht den Algorithmusnamen, den Salt und die Markierungen SH2 und PB2 in der Konfiguration. In den genannten Notizen steht keine Iterationszahl, die sich in ein Ticket kopieren ließe. „Im Backup ist dieses Konto bereits PB2“ liegt näher an dem Satz, den die Dokumentation trägt, als „also knackt keine GPU das mehr“. Kurze Passwörter und Passwörter aus alten Leaks bleiben bei begrenzter Iteration eine billige Vermutung. Ein langes, pro Konto verschiedenes Zufallspasswort vergrößert den Suchraum. Es schaltet die öffentliche Verwaltungsschnittstelle nicht ab.

Das Upgrade tauscht den alten Hash nicht vor dem Login

Der Satz in der technischen Notiz, der am leichtesten überlesen wird: Nach einem Upgrade von einer älteren Version bleibt das Administratorpasswort als SHA256 gespeichert, bis sich genau dieser Administrator auf der neuen Firmware erfolgreich anmeldet. Sollen alle lokalen Administratoren auf PBKDF2 stehen, muss sich jede Person mindestens einmal anmelden. Wer das noch nicht getan hat, bekommt das Passwort von super_admin von Hand neu gesetzt. Die Firmware-Versionsnummer im Change-Ticket belegt nicht, dass in der Konfiguration kein SH2 mehr steht.

Auch wenn das aktuelle Passwortfeld schon PBKDF2 ist, verschwindet der alte Hash nicht von selbst. Die Notiz schreibt: Aus Gründen der Abwärtskompatibilität bleibt das bisherige SHA256 standardmäßig in der verborgenen Einstellung old-password. Die Verwaltungsoberfläche nach einer normalen Anmeldung zeigt diesen Eintrag nicht. Im Konfigurationsbackup, das super_admin exportiert, ist er sichtbar. Solange dieses alte Material im Backup steht, existiert das Ziel des Offline-Crackings weiter. Die Gegenseite muss nicht warten, bis Sie die Firmware fertig aktualisiert haben. Liegt die Backup-Datei in einem Cloud-Laufwerk, in einem Ticket oder in einem Chat, ist SH2 ein weiteres Mal kopiert.

SH2 aus old-password zu entfernen, läuft über einen eigenen Schalter, nicht als Nebenwirkung des Upgrades. Auf FortiOS 7.2.x und 7.4.x heißt die Einstellung login-lockout-upon-downgrade. In späterer Dokumentation steht der Name login-lockout-upon-weaker-encryption. Beim Einschalten erscheint eine Bestätigungswarnung. Die Release Notes schreiben: PBKDF2 gibt es ab 7.2.11, 7.4.8 und 7.6.1. Ein späteres Downgrade auf eine Version ohne dieses Hash-Verfahren sperrt lokale Administratoren aus. Auch der Weg von 7.2.11 auf 7.4.7, also eine höhere Versionsnummer ohne PBKDF2, fällt unter diese Sperre. Administratoren, die über LDAP, RADIUS oder SAML authentifiziert werden, nutzen diese lokalen Hashes nicht und sind von der Downgrade-Sperre nicht betroffen. Lokale Konten sind das Objekt der Markierungen SH2 und PB2.

Deshalb stehen „alten Hash löschen“ und „heute Nacht müssen wir die Firmware vielleicht zurückrollen“ gegeneinander. Wenn am Vorfallstag noch offen ist, auf welcher PBKDF2-fähigen Version die Firmware landen soll, schalten Sie diese Sperre nicht ein, nur um SH2 zu tilgen. Halten Sie zuerst einen Weg in das Gerät offen. Entfernen Sie das alte Material, nachdem feststeht, dass kein Rollback mehr kommt. Die Empfehlung der Meldung, PBKDF2 zu bestätigen und schwächere Althashes zu entfernen, meint genau diesen Abschnitt der Herstellernotiz. Sie ist kein Synonym dafür, im Portal einmal das Passwort zu ändern.

Die Aussperrung passiert nach der erfolgreichen Anmeldung

Die erste Reaktion auf die Meldung ist oft: alle Administratorpasswörter einmal zurücksetzen. Ein Reset macht den alten Klartext ungültig, den die Gegenseite noch nicht benutzt hat. Wenn Sie noch hineinkommen, kann er die Speicherung von SH2 nach PB2 schieben. Er erledigt nicht den Fall, in dem die Gegenseite sich schon mit Ihrem Konto angemeldet und dieses Konto selbst verändert hat. Die Meldung beschreibt das Löschen oder Ändern des Passworts ursprünglicher Konten, sodass legitime Administratoren sich nicht mehr anmelden können, und gleichzeitig das Anlegen von Konten, die es vorher nicht gab, um den eigenen Zugang zu halten. Eine fehlgeschlagene Anmeldung am VPN-Portal belegt dann: Diese Zugangsdaten akzeptiert das Gerät nicht mehr. Sie belegt nicht: Die Gegenseite hat kein neues Konto.

Im Ticket gehören deshalb zwei Spalten hin. Eine für Passwort und Hash: Steht jeder lokale Administrator jetzt auf SH2 oder auf PB2, liegt im Backup noch old-password, und ist das neue Passwort dasselbe wie bei E-Mail, Cloud-Konsole oder einem anderen VPN. Eine für die Kontoliste: Gibt es lokale Administratoren, die es vor der Meldung nicht gab, sind alle bestehenden Sitzungen beendet, und ist die öffentliche Verwaltungsschnittstelle noch für beliebige Adressen offen. Phishing-resistente Mehrfaktor-Authentifizierung sorgt dafür, dass ein Passwort allein Remote-Verwaltung und VPN nicht öffnet. Sie löscht kein neues Konto, das schon in der Konfiguration steht, und sie holt einen bereits kopierten alten Hash nicht aus der GPU-Warteschlange der Gegenseite zurück.

Den Satz zur Ransomware sollten Sie nicht vorziehen. Die Meldung sagt, der Erstzugang werde weitergegeben. Sie sagt nicht, jede Firewall, die noch SHA-256 nutzt, werde heute verschlüsselt. Geräte, auf die Sie nicht mehr kommen, behandeln Sie als Geräte mit unbestätigter Integrität: isolieren, Konfiguration und Konten prüfen, danach über Wiederherstellung sprechen. Geräte, auf die Sie noch kommen, ziehen zuerst die öffentliche Verwaltungsfläche ein, beenden Sitzungen, setzen lokale Administratoren von SH2 auf PB2 und verwahren das neue Passwort getrennt. In beiden Fällen schreiben Sie nicht dieselbe neue Zeichenfolge in eine Gruppenankündigung.

Vor Ort prüfen: Backup-Markierung, kein Cracking

Versionsnummer, Schlagzeile und der Vermerk „bereits aktualisiert“ ersetzen die Hash-Markierung in dieser Konfiguration nicht. Die vier Schritte setzen voraus, dass Sie dieses Gerät bereits als Administratorin oder Administrator verwalten dürfen. Öffnen Sie das Backup nicht auf einem Rechner, dem Sie nicht vertrauen, und laden Sie es nicht in ein generatives Chatfenster hoch, damit jemand „nach SH2 schaut“.

  1. Legen Sie die Firmware neben die drei Schwellen 7.2.11, 7.4.8 und 7.6.1. Liegt der Zweig unter der jeweiligen Schwelle, markiert die Herstellernotiz den Hash lokaler Administratoren weiter als SHA256. Eine Version über der Schwelle heißt nur: Eine neue Anmeldung kann als PB2 geschrieben werden. Sie heißt nicht, dass alte Konten schon umgeschrieben sind.
  2. Exportieren Sie als super_admin ein Konfigurationsbackup und suchen Sie auf dem eigenen Rechner nach SH2, PB2 und old-password. Nur wenn ein Konto ausschließlich PB2 hat und kein old-password, dürfen Sie in die Notiz schreiben: In diesem Backup ist das alte SHA-256 nicht zu sehen. Dass die Oberfläche das verborgene Feld nicht anzeigt, ist kein Beleg, dass der alte Hash gelöscht wurde.
  3. Listen Sie die lokalen Administratoren und markieren Sie Konten, die sich nach dem Upgrade nie angemeldet haben und deren Passwort ein Super-Admin auch nicht neu gesetzt hat. Die Notiz schreibt, dass diese Konten auf SHA256 bleiben, bis Anmeldung oder Neusetzen passiert. Konten mit entfernter Authentifizierung gehören nicht in denselben Schluss wie diese lokalen Hashes.
  4. Wenn Sie login-lockout-upon-downgrade erwägen, oder den in der Dokumentation genannten Namen login-lockout-upon-weaker-encryption, lesen Sie zuerst die Downgrade-Warnung in den Release Notes und stellen Sie sicher, dass kurzfristig kein Rollback auf eine Version ohne PBKDF2 ansteht. Nach dem Einschalten kommen lokale Administratoren, die nur noch PBKDF2 haben, auf genau diesem Rollback nicht mehr hinein.

Diese vier Schritte beantworten, wie diese Konfiguration Administratorpasswörter jetzt speichert. Sie beantworten nicht, ob in der GPU-Warteschlange der Gegenseite eine ältere Kopie liegt. Hat der Hash das Gerät einmal verlassen, macht eine geänderte Speicherung auf Ihrem Rechner diese Kopie nicht ungültig. Ungültig wird sie, indem Sie das Passwort selbst wechseln und prüfen, dass das Material des neuen Passworts nicht als SH2 in old-password liegen bleibt. Ob die öffentliche Verwaltungsfläche zu ist, steht in der Schnittstellenrichtlinie, nicht im Hash-Präfix.

Vier Lesarten, die über die Meldung hinausgehen

Erstens: „Die Firmware ist 7.2.11 oder höher“ wird gelesen als „SHA-256 steht nicht mehr in der Konfiguration“. Die Notiz bindet die Umstellung an die erfolgreiche Anmeldung dieses Administrators oder an das Neusetzen des Passworts und lässt den alten Hash standardmäßig im verborgenen Feld. Die Versionsnummer ist der Startpunkt. Den Abschluss markiert sie nicht.

Zweitens: PBKDF2 wird gelesen als „wiederverwendete Passwörter gelten nicht mehr“. Eine langsame Ableitung hebt den Preis einer Offline-Vermutung. Klartext, der schon von einer anderen Site, aus einem alten Leak oder aus Infostealer-Logs vorliegt, wird bei der Anmeldung unverändert geschickt. Verschiedene Passwörter an verschiedenen Stellen halten diesen Weg auf. Sie ersetzen nicht das Einziehen der Verwaltungsschnittstelle.

Drittens: „Ich habe das Passwort geändert“ wird gelesen als „eine Aussperrung kommt nicht vor“ oder als „eine bestehende Aussperrung löst dasselbe Zurücksetzen“. Ein Passwortwechsel setzt voraus, dass Sie diese Änderung noch absenden können. Hat die Gegenseite das Konto gelöscht oder das Passwort getauscht, heißt der Fehler im Portal nur: Die alten Zugangsdaten werden nicht akzeptiert. Das neue Passwort löscht den von der Gegenseite angelegten Administrator nicht mit.

Viertens: „Diese Zeichenfolge steht nicht in der lokalen Liste schwacher Passwörter“ wird gelesen als „in der Hash-Warteschlange von FortiBleed fehlt sie“ oder als „diese Firewall ist schon auf PBKDF2“. Der Listenabgleich passiert im Browser-Tab. Die Hash-Markierung steht im Konfigurationsbackup. Die beiden Belege stempeln einander nicht ab. Ein Fehltreffer kann trotzdem ein langes, wiederverwendetes Passwort sein. Ein Treffer heißt nur, dass die Zeichenfolge zu häufig ist. Er beweist für sich nicht, dass diese FortiGate bereits kompromittiert wurde.

Häufige Fragen

Verschwindet SHA-256 sofort nach dem Upgrade auf FortiOS 7.2.11?

Nein. Die Herstellernotiz schreibt: Ab 7.2.11, 7.4.8 und 7.6.1 werden lokale Administratorpasswörter als PBKDF2 gespeichert. Nach dem Upgrade bleibt SHA256 stehen, bis sich der betreffende Administrator erfolgreich anmeldet oder super_admin dieses Passwort neu setzt. Der alte Hash liegt standardmäßig weiter im verborgenen old-password. Das Konfigurationsbackup von super_admin zeigt ihn, die normale Verwaltungsoberfläche nicht. Den alten Hash zu entfernen braucht eine eigene Richtlinie von der Art der Downgrade-Sperre. Danach gilt: Auf einer Version ohne PBKDF2 kommen lokale Administratoren nicht mehr hinein.

Hilft gestohlener Klartext nach dem Wechsel auf PBKDF2 noch?

Ja. PBKDF2 verteuert den Fall „nur ein Hash, jede Vermutung einzeln rechnen“. Hat die Gegenseite den Klartext schon aus einem alten Leak oder aus Infostealer-Logs, schickt sie diese Zeichenfolge beim Login direkt und muss den Hash nicht mehr knacken. Wird dasselbe Passwort zwischen E-Mail, VPN und Administratorkonto wiederverwendet, macht eine langsame Ableitung aus diesem Klartext keinen falschen.

Hilft ein weiteres Passwort, wenn Sie schon ausgesperrt sind?

Der eine Passwortwechsel im Portal setzt voraus, dass Sie sich noch anmelden können. Die Meldung schreibt: Die Gegenseite kann das ursprüngliche Konto löschen oder dessen Passwort ändern, sodass legitime Administratoren nicht mehr hineinkommen, und gleichzeitig Konten anlegen, die es vorher nicht gab. Dann isolieren und die Konfiguration prüfen Sie aus der Lage „wir kommen nicht auf das Gerät“. Das ist kein Abschluss durch ein weiteres Zurücksetzen. Ein Passwortwechsel ersetzt auch keinen alten Hash, der in der Firmware noch nicht umgestellt wurde oder weiter in old-password liegt.

Beweist die lokale Liste schwacher Passwörter, dass der Firewall-Hash nicht geknackt wurde?

Nein. Die lokale Liste beantwortet nur, ob diese Zeichenfolge in der öffentlichen Häufigkeitsliste des aktuellen Tabs und in wenigen Varianten vorkommt. Sie fragt FortiBleed nicht ab und liest keine Firewall-Konfiguration. Ein Fehltreffer beweist weder, dass dieses Passwort nie geleakt wurde, noch dass der Hash auf dem Gerät schon PBKDF2 ist. Ein Treffer heißt nur: Die Zeichenfolge ist zu häufig, sie sollte gewechselt werden, und sie sollte nicht weiter wiederverwendet werden.

Das neue Passwort bleibt auf diesem Rechner

Nachdem die Speicherung von SH2 auf PB2 gewechselt ist, brauchen Sie weiterhin ein Administratorpasswort, das anderswo nicht vorkommt. Diesen Schritt erledigt der Passwort-Generator von FastPwd im aktuellen Tab. Keine Registrierung, und auf der Site gibt es keinen Passwort-Tresor. Der Zufallsmodus nutzt crypto.getRandomValues, die Länge ist 6–128 Zeichen, Standard 16. Unter 8 Zeichen erscheint der Hinweis, dass die Sicherheit niedriger ist. Das Ergebnis wird standardmäßig nicht hochgeladen. Der Generator meldet sich nicht an Ihrer Firewall an, er schreibt SH2 nicht in PB2 um, und er schließt die öffentliche Verwaltungsschnittstelle nicht. Er liefert eine Zeichenfolge, die Sie nicht aus „admin“, Firmenname und Jahreszeit zusammensetzen, für das lokale Konto, in das Sie noch hineinkommen.

Öffnen Sie in den Entwicklertools Network, behalten Sie das Protokoll und suchen Sie in Anfragezeile und Anfragekörper nach der vollständigen neuen Zeichenfolge. In den fachlichen Anfragen sollte sie nicht stehen. Dieser Schritt belegt: Sie hat den Tab diesmal nicht als HTTP-Körper verlassen. Er belegt nicht, dass Sie sie danach in einen Chat eingefügt haben. Fragt der Browser, ob er das Passwort speichern soll, lehnen Sie ab. Die gespeicherte Passwortliste des Browsers ist eine andere Tür und hat mit PB2 in FortiOS nichts zu tun. Ein Zufallspasswort mit Standardlänge 16 aus Großbuchstaben, Kleinbuchstaben, Ziffern und Zeichen hat einen Suchraum, der weit über die kurzen Wörter hinausgeht, die beim Spraying üblich sind. Schreiben Sie daraus nicht „also rechnet SHA-256 das niemals aus“ und nicht „also darf die Verwaltungsschnittstelle im öffentlichen Netz bleiben“.

Wenn Sie zusätzlich sehen wollen, ob eine Zeichenfolge wie ein schwaches Passwort aus einer öffentlichen Häufigkeitsliste aussieht, nehmen Sie eine andere, wegwerfbare Testzeichenfolge mit in Passwortstärke prüfen. Das geprüfte Passwort wird nicht hochgeladen. Abgeglichen wird eine öffentliche Liste, die mit der Seite geladen wird, nicht Have I Been Pwned und nicht die Hash-Bestände von FortiBleed. Ein Fehltreffer beweist nicht, dass das Netz die Zeichenfolge nie gesehen hat. Fügen Sie das Firewall-Passwort, das Sie gleich einsetzen wollen, nicht in das Prüffeld ein, und legen Sie das Konfigurationsbackup nicht zur Prüfung vor.

Muss das neue Passwort einmal eine andere Bereitschaftsperson erreichen, schreiben Sie es nicht in eine Gruppennachricht oder in einen Tickettext, der auf einem Server liegen bleibt. Nutzen Sie den Einmal-Link: Der Server speichert nur Chiffretext, der Schlüssel steht hinter # im Link, und Erstellen wie Lesen brauchen kein Konto. Die Form ist s.html?id={id}#{key}. Dieser Kanal beantwortet, wie Sie etwas einmal übergeben. Er beantwortet nicht, wie Sie die Firewall reparieren. Enthält das Konfigurationsbackup SH2 oder old-password, legen Sie die ganze Datei nicht in den Einmal-Link und nicht in ein Cloud-Laufwerk. Das Backup bleibt auf einem Rechner, dem Sie bereits vertrauen, und wird danach nach Ihrer eigenen Aufbewahrungsregel für Konfigurationen behandelt. Ein Screenshot oder das Weiterleiten des vollständigen Links lässt „nach dem Lesen“ diese Kopie nicht erfassen.

Weiterlesen

Was eine lokale Liste schwacher Passwörter an häufigen schwachen Passwörtern festhält und warum sie kein netzweiter Abgleich und kein Hash-Bestand eines einzelnen Vorfalls ist, steht in Was eine lokale Liste geleakter Passwörter beweisen kann – und warum das kein netzweiter Abgleich ist. Beim Erzeugen eines Passworts gehört ein kryptographisch sicherer Zufall hin, nicht Math.random; siehe Warum ein aus Math.random erzeugtes Passwort zufällig wirkt und trotzdem nicht kryptographisch sicher ist. Warum ein einmaliger Schlüssel hinter der Raute eines Links liegt und der Server das Fragment standardmäßig nicht erhält, steht in Warum sich ein Schlüssel hinter der URL-Raute eignet – und wann der Schutz fällt.