Perché non è necessario archiviare le password come semplici hash SHA-256

SHA-256 non è un archivio di password; è un hashing veloce. Il semplice SHA-256 offre agli aggressori la stessa velocità di indovinare, rendendolo inadatto nonostante sia un algoritmo crittograficamente potente.

Uno sviluppatore implementa un sistema di accesso e memorizza le password come hash SHA-256. L'algoritmo è crittograficamente potente e l'applicazione non applica salt, mantenendo il codice semplice. Quando un utente accede, l'applicazione esegue l'hashing dell'invio e lo confronta con il valore archiviato. Questo design è elegante nella sua semplicità ed è completamente inadatto alla memorizzazione delle password. Questa non è una preoccupazione teorica; è l'errore grave più comune nei sistemi di autenticazione. Il design sembra difendibile finché non si considera cosa può fare un utente malintenzionato con i dati rubati.

Il difetto non è che SHA-256 sia debole. SHA-256 è un robusto algoritmo crittografico, considerato affidabile dalla comunità della sicurezza e utilizzato in tutto il settore per i controlli di integrità e l'indirizzamento dei contenuti. Il difetto è che SHA-256 è veloce, e veloce è esattamente l'opposto di ciò di cui hanno bisogno le password. Un hash della password non è semplicemente una primitiva crittografica; è un tipo specifico di strumento progettato per un problema specifico: la difesa contro le ipotesi. La velocità è una caratteristica dei checksum; nelle password, è una catastrofe.

La rapidità è lo scopo di SHA-256: i controlli di integrità richiedono velocità e un utente malintenzionato ottiene la stessa velocità per indovinare

Quando un database di hash delle password SHA-256 viene compromesso, un utente malintenzionato non ha bisogno di invertire gli hash. L'aggressore crea un dizionario: password comuni come "password", "123456", "ciao" e milioni di altre. Ogni candidato viene sottoposto ad hashing con SHA-256, un'operazione computazionalmente banale, e confrontato con il database rubato. Un utente malintenzionato può calcolare i valori SHA-256 candidati con la stessa primitiva veloce utilizzata dal servizio di accesso, quindi confrontare ciascun risultato offline senza limiti di velocità. La velocità esatta dipende dall'hardware e dall'implementazione, quindi questo articolo non fa deliberatamente alcuna richiesta di ipotesi al secondo o tempo di violazione.

La velocità è l'intero problema. SHA-256 è pensato per essere veloce. Questo è il suo intento progettuale. Ti consente di verificare i checksum dei download, calcolare gli indirizzi dei contenuti e creare alberi Merkle senza attendere. In queste applicazioni, la velocità è una caratteristica. Per le password, la velocità è una catastrofe. Quando un database di password viene rubato e sottoposto ad hashing con SHA-256, l'aggressore ha la stessa velocità di indovinamento del server legittimo per la verifica. Questa simmetria è ciò che rompe la sicurezza della password. Sia il server legittimo che l'aggressore ricevono il vantaggio di un rapido digest generale; solo l’aggressore può ripeterlo offline senza i controlli di accesso dell’applicazione.

Dizionari e tabelle arcobaleno: precalcolo rispetto agli hash non salati e cosa cambia il sale

È qui che un dizionario precompilato diventa pratico. Un utente malintenzionato può impiegare un giorno e calcolare gli hash SHA-256 per le migliaia di password più comuni, per modelli comuni come Nome1990 o per interi dizionari in più lingue. La tabella risultante è chiamata tabella arcobaleno. La ricerca di un hash SHA-256 rubato rispetto a una tabella precalcolata è immediata. Anche senza una tabella precalcolata, calcolare un miliardo di ipotesi è banale con l'hashing accelerato GPU. Il costo computazionale per l'aggressore è così basso che anche le password più deboli cadono in pochi minuti.

Il calcolatore di hash ToolAcre SHA dimostra direttamente questa velocità. Incolla un breve testo, fai clic sul pulsante SHA-256 e il risultato è immediato. Quel risultato immediato, la proprietà che ammiri in un calcolatore di hash, è la proprietà esatta che rende il semplice SHA-256 indifendibile per le password. Un utente malintenzionato ottiene lo stesso risultato istantaneo per ogni ipotesi. Per i checksum e i controlli di integrità, questa velocità è perfetta. Per le password, è fatale per la sicurezza.

Cosa aggiungono le funzioni di hashing della password: fattori di lavoro, durezza della memoria e sali per utente in bcrypt, scrypt, Argon2 e PBKDF2

Un salt è un valore casuale aggiunto alla password prima dell'hashing, quindi il salt di ciascun utente è diverso. Anche se due utenti hanno la stessa password, hanno valori diversi. Ciò interrompe le tabelle arcobaleno precalcolate; un utente malintenzionato deve calcolare la tabella in modo indipendente per ciascun sale. Con i salt per utente generati in modo indipendente, una tabella precalcolata non si applica più invariata a ogni account. Tuttavia, un salt spinge l'attaccante a calcolare la tabella solo durante l'attacco anziché prima. Se l'hashing è ancora veloce, l'attaccante calcola semplicemente più tabelle in parallelo e continua a indovinare ciascun account con una primitiva veloce. Il sale è necessario ma non sufficiente. Impedisce il riutilizzo del dizionario tra le vittime, ma non rallenta l'operazione principale dell'aggressore: indovinare. La velocità dell'hashing è ancora la velocità dell'ipotesi.

Esempio pratico: quanto velocemente viene riconosciuto SHA-256 di una password comune rispetto a un hash di password ottimizzato, descritto qualitativamente

Una funzione di hashing della password adotta un approccio diverso. Bcrypt, scrypt, Argon2id e PBKDF2 sono creati appositamente per la verifica della password. Includono tutti un fattore lavoro: un parametro che rende l’hashing volutamente costoso. Argon2 è il più moderno; regola sia il tempo di CPU che il consumo di memoria. Bcrypt utilizza un fattore di costo personalizzabile che raddoppia il lavoro con ogni incremento. Tutti includono la generazione di sale integrata. Questi strumenti sono progettati pensando al modello dell’aggressore. Il fattore lavoro è fondamentale.

Una funzione di hashing della password rende il costo configurato parte di ogni verifica. Un utente malintenzionato che vuole testare i candidati deve anche pagare quel costo per ogni ipotesi. I tempi concreti non possono essere copiati in modo sicuro tra le distribuzioni, motivo per cui la sezione sui parametri richiede un benchmarking sulla classe di produzione effettiva dell'hardware. Questa asimmetria è ciò che fa funzionare l’hashing delle password. Il fattore lavoro si sposta dal “vantaggio dell’attaccante” al “vantaggio del difensore”.

Migrazione di una tabella SHA-256 legacy: racchiudere gli hash esistenti e ripetere l'hashing all'accesso successivo

Il confronto effettuato rimane qualitativo perché questo repository non contiene benchmark per una particolare funzione della password o un utente malintenzionato. Una password comune produce immediatamente lo stesso SHA-256 immediatamente ogni volta, quindi una voce di dizionario esistente può identificarla per uguaglianza. Un record di password ottimizzato include i propri parametri di sale e di costo e richiede un lavoro configurato per ciascun candidato.

Questo contrasto stabilisce l’errore di progettazione senza promettere ipotesi al secondo. L'hardware, l'implementazione e i parametri selezionati determinano i tempi. La conclusione difendibile è invariante: un digest generico non ha un fattore di lavoro o un costo di memoria regolabile, mentre una funzione di hashing della password viene scelta appositamente per imporre tali costi.

Cosa non copre: la scelta dei parametri per un hash della password specifico, che dipende dall'hardware e dal modello di minaccia

La selezione dei parametri è deliberatamente esterna a questa calcolatrice e a questo articolo. Le impostazioni corrette dipendono dai budget di latenza del server, dalla memoria disponibile, dalla concorrenza e dall'attuale modello di minaccia, quindi copiare un valore fisso da una distribuzione non correlata trasformerebbe un controllo di sicurezza in folklore. Confronta la funzione della password selezionata sull'hardware di produzione e rivisitala man mano che la capacità cambia.

ToolAcre non può eseguire quell'esercizio: il suo pannello accetta testo e un identificatore SHA, quindi restituisce un semplice digest. Non espone alcun campo di sale, impostazione di memoria, controllo di iterazione o formato di registrazione della password. Tale assenza è un utile segnale di confine, non una funzionalità mancante su cui aggirare eseguendo ripetutamente l'hashing di una password nella casella di testo.

Conclusione: il risultato immediato è l'avviso: il calcolatore di hash ToolAcre SHA mostra quanto è veloce SHA-256, motivo per cui non deve contenere le password dei tuoi utenti

È possibile eseguire la migrazione di un sistema legacy che memorizzava le password come semplici SHA-256 senza richiedere a tutti gli utenti di reimpostarle immediatamente. La tecnica è quella di "avvolgere" il vecchio hash: prendere il valore SHA-256 e sottoporlo nuovamente ad hash con Argon2. Al successivo accesso dell'utente, il sistema controlla se il vecchio SHA-256 corrisponde; in tal caso, calcola Argon2 su quel risultato e memorizza la versione incapsulata. Al successivo accesso dell'utente, il sistema effettua la verifica direttamente rispetto ad Argon2. La migrazione avviene in modo trasparente durante il normale flusso di accesso.

Questo approccio avvolto garantisce che le password più vecchie che sono state compromesse siano ora protette dal fattore lavoro. Un utente malintenzionato con il vecchio database di hash SHA-256 non può più semplicemente violarli; devono attaccare la versione incartata, che include il costo di Argon2. La migrazione avviene in modo trasparente per gli utenti durante il normale flusso di accesso. Ogni accesso crea un'opportunità per rafforzare l'hash senza interrompere l'esperienza dell'utente. La scelta del fattore di lavoro corretto dipende dall'hardware e dal modello di minaccia. Le impostazioni predefinite di Argon2 sono sensate: iterazioni 19, memoria 512 MB e parallelismo 1 per i servizi web.