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

    10 è l'attuale valore predefinito; 12 è comune per i nuovi sistemi; 14 è paranoico. 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 Paranoico; ritardo di accesso evidente

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.

Sì — il fattore di lavoro è simmetrico. Verificare un hash a costo 14 richiede 16 volte più tempo rispetto a uno a costo 10. Regola in base al tuo throughput di accesso.

Strumenti correlati