BCrypt-Hash-Überprüfung

Um bei den Abhilfemaßnahmen für CVE-2022-xxxx zu unterstützen, können Sie mit diesem Tool Ihre Datenbank auf Hashes überprüfen, die aktualisiert werden müssen.

Nachdem Sie die Anwendung in Ihre Datenbank integriert haben, arbeitet das Tool in zwei Schritten.

Um dies zu demonstrieren, wird eine In-Memory-Beispielanwendung verwendet. In dieser Beispielanwendung können Sie den Schritt check wie folgt ausführen:

./mvnw spring-boot:run@check

Dadurch wird die Beispieldatenbank auf BCrypt-Hashes überprüft, die aktualisiert werden müssen.

Dann können Sie den Schritt update wie folgt ausführen:

./mvnw spring-boot:run@update

Dies versucht, alle erkannten anfälligen Hashes in der Beispieldatenbank zu aktualisieren.

Die Beispielanwendung verwendet die bereitgestellte Klasse VulnerabilityCheck, um jeden Passwort-Hash zu überprüfen und zu aktualisieren.

Konfiguration für Ihre Datenbank

WARNUNG: Fahren Sie mit diesen Schritten erst fort, nachdem Sie Ihre Anwendung aktualisiert haben, um eine niedrigere Rundenzahl als 31 zu verwenden. OWASP empfiehlt derzeit einen Wert von 10, obwohl auf einigen leistungsstarken Systemen Werte bis zu 16 verwendet werden.

Das Tool wird mit einer In-Memory-Beispielanwendung zu Testzwecken ausgeliefert. Sie müssen diese durch Ihre eigenen Klassen ersetzen, die in Ihre Daten integriert werden.

Klone dazu zunächst dieses Repository.

Ersetzen Sie dann den Code im Paket sample durch Code, der auf die Passwortdaten in Ihrer Anwendung zugreifen kann. Möglicherweise möchten Sie Code schreiben, der vorhandene Passwörter überprüft, um festzustellen, ob sie anfällig sind. Sie möchten Code schreiben, der alle betroffenen Hashes aktualisiert. In beiden Fällen können Sie VulnerabilityCheck verwenden, um einen bestimmten Hash zu überprüfen und zu aktualisieren.

TIPP: Berücksichtigen Sie beim Schreiben des oben genannten Codes, wie viele Passwörter Sie aktualisieren müssen. Denken Sie daran, dass die Datenbankverbindung fehlschlagen kann, Computer abstürzen können, der Arbeitsspeicher ausgehen kann usw. Es ist beispielsweise nicht ratsam, Millionen von Datensätzen auf einmal in den Speicher zu laden.

Nachdem Sie die Passwort-Hashes aktualisiert haben, können Sie nun auf die neueste Spring Security aktualisieren. Wenn Sie die Passwortaktualisierungsfunktion von Spring Security verwenden, wird das Passwort der Benutzer bei der Anmeldung automatisch auf Ihren neu konfigurierten Rundenzwert neu gehasht.

FAQ

F: Woran erkenne ich, ob meine Hashes anfällig sind?

A: Sie sind anfällig, wenn sie mit der Klasse BCrypt von Spring Security mit einem Arbeitsfaktor von 31 gehasht wurden. Sie können dies überprüfen, indem Sie die von Spring Security verwalteten Passwort-Hashes in Ihrem System überprüfen. Wenn sie mit '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' oder '$2$31' beginnen, dann ist dieses Passwort anfällig und muss aktualisiert werden.

F: Wie sollte ich meine Anwendung ändern?

A: OWASP empfiehlt einen Arbeitsfaktor von 10 für BCrypt. Einige leistungsstärkere Systeme verwenden einen Wert von bis zu 16. Jedes System ist anders, und BCrypt ist so konzipiert, dass der Arbeitsfaktor bei Bedarf im Laufe der Zeit erhöht werden kann.

F: Wo ändere ich meine Anwendung?

A: Sie setzen den Arbeitsfaktor wahrscheinlich, indem Sie einen BCryptPasswordEncoder wie folgt konstruieren:

new BCryptPasswordEncoder(31)

Er könnte in einer Bean-Definition wie dieser erscheinen:

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(31);
}

Sie können nach dieser Zeichenfolge suchen und sie aktualisieren. Beachten Sie, dass der Arbeitsfaktor in Ihrer Anwendung möglicherweise durch eine externe Eigenschaft gesteuert wird, was bedeutet, dass Sie ihn stattdessen in Ihrer externen Konfiguration ändern möchten.

F: Ich habe gerade Spring Security aktualisiert und jetzt hängen einige oder alle Anmeldungen und Benutzerregistrierungen. Was ist passiert?

A: Ab Spring Security 5.5.7+, 5.6.4+, 5.7.0+ benötigen Passwort-Hashes mit einem Arbeitsfaktor von 31 – zum Beispiel beginnend mit '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' oder '$2$31' – 2–3 Tage für jede Hash-Berechnung. Um dies zu beheben, müssen Sie Spring Security so ändern, dass es eine niedrigere Rundenzahl verwendet. Verwenden Sie dann dieses Tool, um die anfälligen Passwort-Hashes zu aktualisieren.

F: Ich habe alle drei empfohlenen Schritte abgeschlossen (BCryptPasswordEncoder-Konfiguration ändern, Passwort-Hashes aktualisieren und Spring Security aktualisieren). Die geänderten Passwort-Hashes werden nicht auf meinen neu konfigurierten Arbeitsfaktor aktualisiert. Was soll ich tun?

Stellen Sie sicher, dass Sie einen Bean vom Typ UserDetailsPasswordService veröffentlicht haben. Dieser Bean wird verwendet, um Passwörter auf eine neue BCrypt-Rundenzahl zu aktualisieren.

F: Warum kann Spring Security die anfälligen Passwörter nicht einfach zur Upgrade-Zeit aktualisieren, ohne dass dieses Tool erforderlich ist?

Erstens, weil Passwort-Hashes mit einem Arbeitsfaktor von 31 in der neuesten Spring Security korrekt berechnet werden und somit 2–3 Tage für jede Berechnung benötigen. Es ist eine unpraktische Erwartung zu glauben, dass dies eine zumutbare Belastung für Anwendungen darstellt.

Zweitens unterstützt Spring Security nur die Erhöhung des Arbeitsfaktors (z. B. von 10 auf 12), nicht die Verringerung (z. B. von 31 auf 10).