Come funziona Bcrypt: sale, fattore di costo e limiti

La prima volta che ho spedito un sistema di login, ho fatto la cosa che ogni tutorial di quell'epoca mi diceva di fare: memorizzato md5($password) nella tabella utenti e sono andato avanti Ha funzionato, ed è stato tranquillamente un disastro Anni di creazione di auth nei plugin WordPress e nelle app Laravel in seguito, ho un rispetto molto più sano per il divario tra & quot; il controllo password pass" e & quot; le password sono sicure se questo database perde." Bcrypt è lo strumento che colma la maggior parte di quel divario, ed è l'impostazione predefinita in quasi tutti i framework che raggiungo Così ho costruito un generatore bcrypt innanzi Toolz.dev che hash una password con un fattore di costo che controlli, verifica una password rispetto a un hash esistente e fa tutto nel tuo browser in modo che nulla di ciò che digiti venga mai inviato da nessuna parte Questa è la guida ad esso e a bcrypt stesso.

tl; dr: Bcrypt trasforma una password in un hash salato, volutamente lento di 60 caratteri, quindi un database trapelato non è un elenco di password trapelato Il Toolz generatore bcrypt esegue l'hashing di qualsiasi password con un fattore di costo regolabile (da 4 a 31), verifica una password rispetto a un hash incollato e mostra la versione, il costo e il sale analizzati Produce lo standard $2b$ formatta che OpenBSD, PHP password_hashLe librerie bcrypt Laravel e Node accettano tutte e funziona interamente lato client.

Che cos'è bcrypt?

Bcrypt è una funzione di hashing delle password progettata da Niels Provos e David Mazieres e presentata nel loro documento USENIX del 1999 & quot; Uno schema di password e quot adattabili al futuro;. È costruito sul cifrario a blocchi Blowfish, ma con una svolta: invece di crittografare i dati, esegue Blowfish's passo di impostazione della chiave più e più volte, utilizzando la password e un sale casuale come materiale chiave Il risultato è un hash unidirezionale che è economico da calcolare una volta e costoso da calcolare un miliardo di volte, che è esattamente la proprietà di archiviazione della password esigenze.

Che & quot; costoso su scopo& quot; idea è il cuore di esso Un hash di uso generale come SHA-256 è progettato per essere veloce, perché checksum e controlli di integrità vogliono velocità Password hashing vuole il contrario Se un utente malintenzionato ruba il tuo database, l'unica cosa che si frappone tra loro e ogni password in chiaro è quanto tempo ci vuole per indovinare Un hash veloce consente a una GPU moderna di testare miliardi di candidati al secondo; un hash bcrypt a un costo sensato limita che a poche migliaia al secondo per core Stesso file trapelato, risultato selvaggiamente diverso.

Bcrypt è sopravvissuto più di due decenni perché ha ottenuto i fondamenti giusti e perché è adattabile Il fattore di costo significa che lo stesso algoritmo che è stato sintonizzato per l'hardware del 1999 può essere composto per l'hardware del 2026 senza cambiare nient'altro Rimane un'opzione consigliata nel Scheda di Cheat per lo Storage delle Password OWASP, ed è l'impostazione predefinita pronta all'uso in Laravel, Spring Security e in molti altri stack in cui lavoro Se desideri uno sfondo più approfondito sul motivo per cui gli hash veloci sono sbagliati per questo lavoro, il strumenti online per la privacy dei dati la guida copre il ragionamento che ha spinto l'intero settore verso un hashing lento e salato.

Cosa contiene un hash bcrypt?

Una delle cose più belle di bcrypt è che il suo output è autodescrivibile Prendi un vero hash:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

Leggi da sinistra a destra, divisi sui simboli del dollaro e ti dice tutto ciò che è necessario per verificare una password rispetto ad essa:

campo	esempio	significato
versione	2b	La variante bcrypt. 2b è il formato OpenBSD corretto corrente
prezzo	12	Il fattore di lavoro La configurazione della chiave esegue 2^12 = 4096 iterazioni
Sale	R9h/cIPz0gi.URNNX3kh2O	22 caratteri di Base64 personalizzato, decodifica a 16 byte casuali
Digerire	PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW	31 caratteri che codificano l'output bcrypt a 23 byte

Poiché il sale e il costo vivono all'interno della stringa, la verifica non ha bisogno di altro Quando si incolla un hash nel generatore bcrypt verifica modalità, legge il costo e sale direttamente fuori dalla stringa, ricalcola il digest con quel sale esatto, e confronta Non c'è colonna di sale separata da gestire, che è uno dei motivi bcrypt è così piacevole da memorizzare: è un singolo campo opaco nella tabella degli utenti.

L'alfabeto Base64 personalizzato vale una nota, perché fa inciampare le persone Bcrypt utilizza ./A-Za-z0-9, che è un ordinamento diverso da Base64 standard Un sale bcrypt non è una stringa Base64 standard, quindi non cercare di decodificarlo con uno strumento Base64 generico e aspettarti byte significativi Se sei curioso della variante standard usata ovunque, il codifica base64 guida cammina attraverso l'alfabeto normale e dove si presenta.

Come si genera un hash bcrypt?

Nello strumento è tre passaggi: digita una password, scegli un costo, fai clic su Genera Sotto il cofano, generare un hash fa più di quello che sembra Per prima cosa viene creato un sale casuale crittograficamente forte di 16 byte utilizzando l'API Web Crypto Quindi bcrypt esegue la sua costosa pianificazione delle chiavi, seminando Blowfish con la password e il sale e iterando 2^cost volte Infine crittografa una stringa magica fissa (& quot; OrpheanBeholderScryDoubt") 64 volte con lo stato di cifratura risultante e Base64-codifica l'output. Tutta quella danza produce l'hash di 60 caratteri.

La singola sorpresa più comune è che l'hashing della stessa password due volte dà due hash diversi Che è corretto e intenzionale Ogni hash ottiene il suo sale casuale, quindi due utenti che scelgono entrambi hunter2 finire con valori memorizzati completamente diversi Un utente malintenzionato che ruba la tabella non può dire che due account condividono una password e non può riutilizzare una tabella precalcolata tra gli account Se si desidera riprodurre un hash specifico per il test, si fornisce la stringa di sale completa anziché un costo nudo, che è esattamente ciò che la modalità di verifica fa internamente.

Nel codice della tua applicazione non assembli mai nulla di tutto ciò a mano Chiami la libreria:

// PHP
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);

// Node with bcrypt / bcryptjs
const hash = await bcrypt.hash(password, 12)

// Laravel
use Illuminate\Support\Facades\Hash;
$hash = Hash::make($password); // bcrypt by default

Lo strumento Toolz è per i momenti attorno a quel codice: controllo sanitario di come appare un hash a un dato costo, generazione di un hash noto per un seeder o un dispositivo di prova o conferma che un hash trovato in una configurazione corrisponde alla password che si pensa che lo faccia.

Come faccio a scegliere un fattore di costo?

Il fattore di costo è l'unica manopola a cui devi pensare, e la risposta onesta è & quot; misura, non copiare.& quot; La regola pratica di OWASP è che un singolo hash dovrebbe impiegare circa un quarto di secondo sul tuo hardware di produzione Quel target bilancia due forze opposte: troppo basso e rendi il cracking economico, troppo alto e ogni accesso legittimo paga il prezzo, il che conta quando un endpoint occupato sta effettuando l'hashing su ogni richiesta.

Poiché il costo è una potenza di due, ogni passaggio raddoppia il lavoro Il costo 11 è due volte più lento del costo 10, il costo 12 è quattro volte più lento Sul tipico hardware del server degli anni 2020, il costo da 10 a 12 atterra nel quartiere giusto, motivo per cui i framework sono predefiniti lì Lo strumento mostra una stima temporale approssimativa mentre trascini il cursore in modo da poter sentire quanto velocemente il costo si compone, ma trattalo come una guida relativa, non come un punto di riferimento del tuo server Il numero reale dipende dalla tua CPU e l'unico modo per conoscerlo è il tempo password_hash sulla scatola che lo eseguirà.

Un modello pratico che vale la pena conoscere: poiché il costo è memorizzato all'interno di ogni hash, puoi aumentarlo nel tempo senza migrazione Su un login riuscito hai il testo in chiaro in mano per un momento, quindi controlli se il costo hash's memorizzato è inferiore al tuo obiettivo attuale e, in tal caso, rihash e aggiornamento PHP lo espone direttamente attraverso password_needs_rehash. Significa che la tua sicurezza tiene il passo con l'hardware senza mai forzare la reimpostazione della password.

Bcrypt rispetto a SHA-256, Argon2 e scrypt

Il confronto che conta di più è bcrypt contro un semplice hash veloce, e contro le più recenti funzioni memory-hard Ecco come si allineano per l'archiviazione delle password:

Funzione	Disinfettato	Lento di proposito	Memoria dura	Buono per le password?
MD5/SHA-256	No (da solo)	no	no	No, fin troppo veloce
bcrypt	Sì, incorporato	Sì, costo sintonizzabile	no	Sì, consigliato
scrypt	certo	certo	certo	certo
Argon2id	certo	certo	certo	Sì, preferito per i nuovi impianti

Un semplice SHA-256 di una password, anche salata, è lo strumento sbagliato: è progettato per la velocità, quindi un database trapelato di hash SHA-256 salati cade rapidamente in una GPU Se hai bisogno solo di un digest veloce per un checksum o una chiave di cache piuttosto che una password, questo è ciò che il generatore hash è per, e la distinzione è il punto centrale Argon2id, il vincitore del Concorso di hashing di password 2015, aggiunge la durezza della memoria, che resiste all'hardware personalizzato che può accelerare bcrypt, ed è la prima scelta per un sistema nuovo di zecca in cui controlli il runtime Ma bcrypt non è obsoleto È testato in battaglia, è l'impostazione predefinita negli strumenti che uso quotidianamente, e sceglierlo è una decisione valida, soprattutto quando il tuo framework lo spedisce L'errore da evitare non è & quot; bcrypt invece di Argon2, & quot; è & quot; un hash veloce invece di uno qualsiasi di essi.& quot; Per un tour più ampio delle utilità di sicurezza che si abbinano all'hing, il Strumenti di produttività per sviluppatori guida ha la mappa.

Che dire del limite di 72 byte e di altri gotcha?

Bcrypt legge solo i primi 72 byte della password Tutto ciò che è passato e viene silenziosamente ignorato, che per le password normali non ha mai importanza ma può mordere una passphrase molto lunga, specialmente una con caratteri UTF-8 multi-byte dove il conteggio dei byte sale più velocemente del conteggio dei caratteri Lo strumento ti avvisa ogni volta che il tuo input attraversa 72 byte UTF-8 quindi il troncamento non è mai una sorpresa silenziosa Alcuni sistemi lavorano intorno al limite pre-hashing la password con SHA-256 e Base64-codificandola prima di consegnarla a bcrypt, che ripiega una password arbitrariamente lunga in un input breve fisso; se lo fai, fallo in modo coerente sia su sign-up che su login.

L'altro gotcha è il prefisso della versione Vedrai $2a$, $2y$, e $2b$ in natura. $2a$ era l'originale, $2y$ era un tag specifico per PHP introdotto dopo che in alcune implementazioni è stato riscontrato un bug di estensione del segno e $2b$ è la versione corrente corretta di OpenBSD Per i nuovi hash che desideri $2b$, che è ciò che questo strumento produce Tutti e tre verificano in modo identico per le normali password ASCII; le differenze emergono solo con particolari byte non ASCII vicino al confine di 72 byte Quando si incolla un token in uno strumento che ispeziona anche le credenziali strutturate, come il Decodificatore JWT, tieni presente che un hash bcrypt non è un token che decodifichi per leggere un payload; è un digest unidirezionale senza nulla da rivelare.

Dove il generatore bcrypt si inserisce in un flusso di lavoro reale

Da solo un hash è solo metà della storia, quindi il mixer si trova accanto agli altri strumenti di credenziali che tengo aperti Quando sto seminando un database di test o impostando un account demo, genero la password stessa con il generatore passwordcontrolla che si liberi una barra di forza sensibile con il verificatore della forza della password, e solo allora eseguirlo attraverso il generatore bcrypt per ottenere l'hash memorizzato Quell'ordine è importante: una password casuale forte dietro un hash bcrypt costo-12 è veramente difficile da decifrare, mentre una password debole dietro lo stesso hash cade ancora in un attacco al dizionario, perché l'aggressore deve solo indovinare la manciata di probabili candidati piuttosto che l'intero spazio delle chiavi Il fattore di costo ti fa guadagnare tempo; l'entropia della password è ciò contro cui viene speso quel tempo.

La modalità di verifica guadagna il suo posto durante il debug Quando un login fallisce misteriosamente nella messa in scena, il modo più veloce per isolare il problema è incollare l'hash memorizzato e la password che ritieni corretta e vedere se corrispondono Una corrispondenza significa che il bug è a monte, nel modo in cui la password raggiunge il controllo; una mancata corrispondenza significa che l'hash memorizzato è stato scritto con una password diversa o una codifica alterata O risposta ti salva dall'indovinare, e poiché l'intera cosa viene eseguita localmente, puoi farlo con un vero hash estratto da un database senza che l'hash abbia mai lasciato la tua macchina È lo stesso principio lato client dietro ogni strumento sul sito, e per qualsiasi cosa tocchi le credenziali non è una gentilezza, è il requisito.

Domande frequenti

È sicuro eseguire l'hashing di una password reale in questo generatore di bcrypt?

Sì, perché l'hashing avviene interamente nel tuo browser e non viene inviato nulla da nessuna parte Puoi confermarlo nella scheda Rete dei tuoi strumenti per sviluppatori: generare un hash non fa alcuna richiesta Detto questo, una scheda del browser non è un gestore di password, quindi evita di incollare le credenziali live di un account di produzione in qualsiasi pagina web che non hai creato e chiudi la scheda quando hai finito.

Perché la stessa password produce ogni volta un hash bcrypt diverso?

Perché bcrypt genera un nuovo sale casuale per ogni hash e lo mescola nel risultato Questa è una funzionalità: due utenti che scelgono la stessa password ottengono comunque hash memorizzati diversi, quindi un utente malintenzionato non può individuare le password condivise o riutilizzare una tabella precalcolata La verifica funziona ancora perché il sale è memorizzato all'interno della stringa di hash stessa.

Quale fattore di costo devo utilizzare per bcrypt?

Utilizza il costo più alto che il tuo flusso di accesso può tollerare senza un fastidioso ritardo, che per la maggior parte dei server degli anni 2020 costa da 10 a 12. OWASP suggerisce che un singolo hash dovrebbe richiedere circa un quarto di secondo sull'hardware di produzione. Poiché ogni passaggio raddoppia il lavoro, misura sul tuo server anziché copiare un numero e aumenta il costo ogni pochi anni man mano che l'hardware accelera.

È possibile invertire un hash bcrypt nella password?

No. Bcrypt è una funzione unidirezionale, quindi non esiste un modo matematico per trasformare un hash nella password originale L'unico attacco è indovinare: un utente malintenzionato esegue l'hashing delle password candidate con lo stesso sale e costo e controlla una corrispondenza Ecco perché il fattore di costo è importante, perché imposta quanto è costosa ogni ipotesi e perché password uniche forti più un costo elevato rendono impraticabile indovinare.

Bcrypt è ancora sicuro nel 2026 o devo passare ad Argon2?

Bcrypt è ancora considerato sicuro per l'archiviazione delle password e rimane un'opzione consigliata nel Cheat Sheet OWASP Password Storage Argon2id, il vincitore del Concorso Password Hashing 2015, è preferito per i nuovi sistemi in cui si controlla il runtime perché resiste anche agli attacchi GPU e hardware specializzato. Bcrypt è una scelta valida, soprattutto quando il tuo framework lo spedisce come predefinito; il vero errore è utilizzare un hash veloce per uso generale invece di qualsiasi funzione di hashing delle password.

Qual è il limite di 72 byte in bcrypt?

Bcrypt legge solo i primi 72 byte della password codificata UTF-8, quindi tutti i caratteri oltre vengono ignorati Per le password normali questo non ha mai importanza, ma una passphrase molto lunga può essere troncata, motivo per cui alcuni sistemi pre-hashano la password con SHA-256 prima di bcrypt Questo strumento ti avvisa ogni volta che il tuo input supera i 72 byte quindi il troncamento non è mai una sorpresa.

Cosa significano i prefissi $2a$, $2b$ e $2y$?

Sono tag di versione per il formato di output bcrypt $2a$ era l'originale, $2y$ era una correzione specifica per PHP per un bug di estensione del segno e $2b$ è la versione OpenBSD corretta corrente Per i nuovi hash $2b$ è corretto, che è ciò che questo strumento verifica tutti e tre in modo identico per le password ASCII; le differenze appaiono solo con determinati byte non ASCII al limite di 72 byte.

Bcrypt è uguale alla crittografia?

No. La crittografia è reversibile con una chiave, quindi i dati crittografati possono essere decrittografati all'originale L'hashing Bcrypt è unidirezionale e volutamente lento, ed è pensato solo per la verifica: non è mai necessario recuperare la password, solo per confermare che qualcuno abbia digitato quella giusta Memorizzare le password con crittografia invece che con hashing è un anti-pattern, perché chi detiene la chiave può recuperare ogni password.