Controllo hash BCrypt

Per supportare le fasi di mitigazione per CVE-2022-xxxx, puoi usare questo strumento per verificare nel tuo database la presenza di hash da aggiornare.

Dopo aver integrato l'applicazione con il tuo database, lo strumento funziona in due fasi.

Per dimostrarlo, viene utilizzata un'applicazione di esempio in memoria. Su quell'applicazione di esempio, puoi eseguire il passaggio check, in questo modo:

./mvnw spring-boot:run@check

Questo controllerà il database di esempio per eventuali hash BCrypt che necessitano di aggiornamento.

Poi, puoi eseguire il passaggio update, in questo modo:

./mvnw spring-boot:run@update

Questo tenterà di aggiornare gli eventuali hash vulnerabili che rileva nel database di esempio.

L'applicazione di esempio usa la classe VulnerabilityCheck fornita per verificare e aggiornare ogni hash delle password.

Configurazione per il tuo database

AVVISO: Procedi con questi passaggi solo dopo aver aggiornato la tua applicazione per usare un numero di round inferiore a 31. OWASP attualmente raccomanda un valore di 10, anche se su alcuni sistemi ad alte prestazioni vengono usati valori fino a 16.

Lo strumento include un esempio in memoria a scopo di test. Dovrai sostituirlo con classi tue che si integrino con i tuoi dati.

Per farlo, clona prima questo repository.

Quindi, sostituisci il codice nel pacchetto sample con codice che possa accedere ai dati delle password nella tua applicazione. Potresti voler scrivere codice che controlli le password esistenti per vedere se sono vulnerabili. Vorrai scrivere codice che aggiorni eventuali hash interessati. In entrambi i casi, puoi usare VulnerabilityCheck per verificare e aggiornare un dato hash.

SUGGERIMENTO: Nello scrivere il codice sopra, tieni in considerazione quante password devi aggiornare. Ricorda di tenere in considerazione che la connessione al database può fallire, i computer possono bloccarsi, la memoria può esaurirsi e così via. Non è consigliabile, ad esempio, caricare milioni di record contemporaneamente in memoria.

Dopo aver aggiornato gli hash delle password, puoi ora aggiornare all'ultima versione di Spring Security. Se stai usando la funzione di aggiornamento password di Spring Security, quando gli utenti accedono, la loro password verrà automaticamente ri-hashata al valore di round appena configurato.

FAQ

D: Come faccio a sapere se i miei hash sono vulnerabili?

R: Sono vulnerabili se sono stati sottoposti a hash usando la classe BCrypt di Spring Security con un work factor di 31. Puoi confermarlo controllando gli hash delle password nel tuo sistema che sono gestiti da Spring Security. Se iniziano con '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' o '$2$31', allora quella password è vulnerabile e deve essere aggiornata.

D: Come dovrei modificare la mia applicazione?

R: OWASP raccomanda un work factor di 10 per BCrypt. Alcuni sistemi ad alte prestazioni useranno un valore fino a 16. Ogni sistema è diverso e BCrypt è progettato per poter aumentare il work factor nel tempo secondo necessità.

D: Dove modifico la mia applicazione?

R: Probabilmente stai impostando il work factor costruendo un BCryptPasswordEncoder in questo modo:

new BCryptPasswordEncoder(31)

Potrebbe apparire in una definizione di bean come questa:

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

Puoi cercare quella stringa e aggiornarla. Nota che il work factor potrebbe essere controllato nella tua applicazione da una proprietà esterna, il che significa che vorrai modificarlo invece nella tua configurazione esterna.

D: Ho appena aggiornato Spring Security e ora alcuni o tutti i login e le registrazioni utente si bloccano. Cosa è successo?

R: A partire da Spring Security 5.5.7+, 5.6.4+, 5.7.0+, gli hash delle password che indicano un work factor di 31 -- ad esempio, che iniziano con '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' o '$2$31' -- impiegheranno 2-3 giorni per completare ogni calcolo dell'hash. Per alleviare questo problema, dovrai modificare Spring Security per usare un numero di round inferiore. Poi, usa questo strumento per aggiornare gli hash delle password vulnerabili.

D: Ho completato tutti e tre i passaggi raccomandati (modificare la configurazione di BCryptPasswordEncoder, aggiornare gli hash delle password e aggiornare Spring Security). Gli hash delle password modificati non vengono aggiornati al work factor appena configurato. Cosa dovrei fare?

Assicurati di avere pubblicato un bean di tipo UserDetailsPasswordService. Questo bean è ciò che viene usato per aggiornare le password a un nuovo log rounds di BCrypt.

D: Perché Spring Security non può semplicemente aggiornare le password vulnerabili al momento dell'aggiornamento senza la necessità di questo strumento?

R: Primo, perché con l'ultima versione di Spring Security, gli hash delle password con un work factor di 31 vengono calcolati correttamente e quindi impiegano 2-3 giorni per completare ciascuno. È un'aspettativa poco pratica supporre che questo sia un costo ragionevole da sostenere per le applicazioni.

Secondo, Spring Security supporta solo l'aumento del work factor (ad esempio da 10 a 12), non la diminuzione (ad esempio da 31 a 10).