Generatore bcrypt

bcrypt è ancora una delle scelte più sicure per memorizzare le password. È deliberatamente lento, deriva il proprio sale e si adatta ai miglioramenti hardware attraverso un parametro di costo regolabile. Questo generatore produce un hash bcrypt conforme agli standard da una password in chiaro, così puoi creare un utente di test, migrare un account tra sistemi o confrontare valori con un hash esistente memorizzato in una colonna users.password.

Come hashare una password con bcrypt

  1. 1

    Inserisci la password in chiaro

    Fino a 72 byte, bcrypt tronca silenziosamente oltre questo limite.

  2. 2

    Scegli un fattore di costo

    12 è il valore predefinito qui; 10 è una scelta legacy più rapida; 13 è l'impostazione più forte di questo strumento. Ogni +1 raddoppia approssimativamente il tempo di hash.

  3. 3

    Viene generato un sale casuale

    16 byte di sale vengono estratti da un RNG crittografico e incorporati nella stringa hash risultante.

  4. 4

    Copia l'hash

    L'output è una stringa auto-descrittiva come `$2b$12$...` che include versione, costo, sale e digest.

Anatomia di un hash bcrypt

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6
  |   |  |                      |
  |   |  sale (22 caratteri Base64)  digest (31 caratteri Base64)
  |   costo (2 cifre, 4-31)
  versione (2a, 2b, 2y, tutti bcrypt)

L’intera stringa è di 60 caratteri. Le colonne di tipo VARCHAR(60) o CHAR(60) sono lo schema standard.

Raccomandazioni sul fattore di costo

Costo Tempo approssimativo per hash (CPU 2024) Caso d’uso
10 ~80 ms Predefinito legacy, ancora accettabile
12 ~300 ms Baseline attualmente raccomandata
13 ~600 ms App più sicure
14 ~1.2 s Fuori dall’intervallo di questo strumento (massimo 13)

Ogni incremento raddoppia il fattore di lavoro. Se la latenza di accesso sotto i 500 ms è critica, rimani su 10-12.

Byte di versione: 2a vs 2b vs 2y

  • $2a$, Specifica originale del 1999. La maggior parte delle librerie emette hash 2a.
  • $2b$, Revisione del 2014 che corregge un bug di troncamento in crypt_blowfish. Preferito per i nuovi hash.
  • $2y$, Tag specifico per PHP, funzionalmente equivalente a $2b$.

Tutti e tre si verificano l’uno contro l’altro; solo il tag nella stringa hash differisce.

Cosa protegge bcrypt

  • Tabelle arcobaleno, Sale unico per hash sconfigge le ricerche precompute.
  • Cracking GPU/ASIC, Il programma chiave Blowfish è vincolato alla memoria e ostile alle GPU. Non è così ostile alle GPU come Argon2, ma è comunque lento da forzare.
  • Fughe di database, Il testo in chiaro non è mai recuperabile dall’hash senza forzare.

Cosa bcrypt NON protegge: password deboli (usa una lunghezza minima e controlla contro le liste di violazione), credential stuffing (usa un secondo fattore), phishing.

Limite di 72 byte

bcrypt utilizza solo i primi 72 byte della password. Input più lunghi vengono troncati silenziosamente, che è lo stesso motivo per cui molte librerie ora raccomandano di pre-hashare la password con SHA-256 prima di passarla a bcrypt. Le alternative moderne (Argon2, scrypt) non hanno tale limite.

Domande frequenti

Sì per la memorizzazione delle password, a costo ≥ 12. OWASP lo elenca ancora come algoritmo accettabile. Argon2id è la scelta preferita per i nuovi sistemi, ma migrare gli hash bcrypt legacy è una preoccupazione a bassa priorità.

Perché il sale è generato casualmente per ogni hash. La verifica prende il sale dall’hash memorizzato, ri-hash la password inviata con esso e confronta.

La maggior parte delle librerie non espone questo, e per una buona ragione, sali prevedibili sconfiggono lo scopo. Usa il sale generato dalla libreria; questo è il percorso sicuro.

Ogni +1 raddoppia approssimativamente il tempo di hash, quindi un costo 13 richiede circa 8 volte più tempo di un costo 10. Resta nell’intervallo 10-12, a meno che la tua applicazione non richieda davvero la forza aggiuntiva.

Strumenti correlati

Strumento disponibile in altre lingue