Generatore e verifica di hash bcrypt

Informazioni su questo strumento

Perché bcrypt è lento di proposito

I database di password vengono rubati, e chi ne possiede uno può tentare di indovinare le password offline, alla velocità che il suo hardware consente. Gli hash generici come SHA-256 sono fatti per essere veloci, tanto che una sola scheda grafica prova miliardi di candidati al secondo. bcrypt, pubblicato da Niels Provos e David Mazières nel 1999, si basa sul costoso key setup del cifrario Blowfish e lo ripete un numero configurabile di volte, così ogni tentativo diventa costoso.

Ogni hash contiene anche un proprio salt casuale di 16 byte. Due utenti con la stessa password ottengono hash diversi, e una tabella precalcolata per un salt non serve a nulla per il successivo. Un hash bcrypt non si può decifrare. L'attacco praticabile è tirare a indovinare, quindi una password debole cade comunque in fretta, qualunque sia il costo.

Che cosa significa il costo e come sceglierlo

Il costo è il logaritmo in base 2 del numero di round di key setup: costo 10 corrisponde a 1.024 round, costo 12 a 4.096. Aumentarlo di uno raddoppia il tempo di un login e di ogni tentativo di un attaccante. Il costo è scritto nell'hash, quindi puoi alzarlo in seguito: i vecchi hash continuano a essere verificati, e puoi ricalcolare l'hash di una password con il nuovo costo al successivo login del suo proprietario.

Scegli il costo più alto che il tuo server può permettersi per un login, e non meno di 10, il minimo indicato per bcrypt dall'OWASP Password Storage Cheat Sheet. Il tempo mostrato qui è misurato in WebAssembly nel tuo browser, di solito più lento del codice nativo su un server, quindi fai la misura sulla macchina che calcolerà gli hash. Per lo stesso motivo questo strumento si ferma al costo 14.

Il limite di 72 byte

bcrypt usa al massimo 72 byte della password. Il limite è in byte, non in caratteri: in UTF-8 una lettera accentata come é occupa due byte, la maggior parte dei caratteri CJK tre e la maggior parte delle emoji quattro o più. Molte librerie troncano gli input più lunghi senza avvisare, per cui due password lunghe che condividono i primi 72 byte risultano valide per lo stesso hash. L'implementazione Go usata qui si rifiuta di calcolare l'hash di input più lunghi, e questo strumento te lo segnala.

Se i tuoi utenti possono scegliere password più lunghe, la soluzione più semplice è rifiutarle in fase di registrazione con un messaggio chiaro. Un workaround diffuso calcola prima l'hash SHA-256 della password e passa a bcrypt il testo Base64 o hex di quel digest. Non deve passare i byte grezzi del digest, perché alcune implementazioni smettono di leggere al primo byte zero, e il cheat sheet OWASP sconsiglia questo tipo di pre-hashing perché apre la strada a un attacco chiamato password shucking. Per un sistema nuovo, OWASP raccomanda Argon2id prima di bcrypt, e Argon2id non ha il limite di 72 byte.

Leggere un hash, e come funziona questo strumento

Un hash bcrypt è lungo 60 caratteri: un prefisso di versione come $2b$, un costo a due cifre e $, 22 caratteri di salt e 31 di digest, entrambi nell'alfabeto Base64 proprio di bcrypt (./A-Za-z0-9). Tutto ciò che serve per verificare una password sta in quell'unica stringa, quindi non c'è una colonna separata per il salt da memorizzare.

Calcolo e verifica sono eseguiti dal package golang.org/x/crypto/bcrypt di Go, compilato in WebAssembly ed eseguito in un thread in background del browser. Password e hash non vengono inviati da nessuna parte né salvati. La pagina è pensata per dati di test, fixture e per verificare un hash che hai già: l'hash delle password degli utenti reali va calcolato dalla tua applicazione, sul tuo server.