Generatore e verificatore di hash delle password

Calcoli e verifichi le password con bcrypt, scrypt, Argon2id e PBKDF2 interamente nel suo browser — generi stringhe in formato PHC, confronti una password candidata con un hash esistente e ispezioni i parametri nascosti al suo interno. Nulla viene caricato.
Solo per password di prova. Le password reali degli utenti non devono mai essere incollate in alcuna pagina web. Questo strumento viene eseguito interamente nel suo browser — le stringhe non lasciano mai la sua scheda — ma una violazione reale inizia con un singolo incolla.
Modalità
Algoritmo (PBKDF2 è presente anche nella scheda KDF delle password della pagina HMAC — qui è pensato per la memorizzazione delle password)
Password (codificata in UTF-8; lasci vuoto solo se intende davvero la password vuota)
Parametri (i valori predefiniti seguono i minimi del Password Storage Cheat Sheet di OWASP 2023)
Costo bcrypt (2^costo round)
Variante bcrypt la variante cambia solo il prefisso; l'hash stesso è identico
scrypt N (costo CPU)
scrypt r / p r =   p = dimensione del blocco 128·r byte; memoria = 128·N·r byte (N=214, r=8 → 16 MiB)
Argon2id m (memoria)
Argon2id t / p t =   p = t = passaggi; p = parallelismo (corsie)
PRF PBKDF2
Iterazioni PBKDF2  OWASP 2023: 600000 per HMAC-SHA-256 (1300000 per SHA-1, 210000 per SHA-384/512)
Lunghezza dell'output (byte)  l'output di bcrypt è fisso a 23 byte (31 caratteri base64 di bcrypt)
Hash (stringa PHC)
Confronto: stessa password, tutti e quattro gli algoritmi (predefiniti della pagina; eseguiti uno dopo l'altro, sia paziente)
AlgoritmoParametriMemoriaLunghezza dell'outputTempo (questo browser)
bcryptcosto 124 KiB23 byte-
scryptN=214, r=8, p=116 MiB32 byte-
Argon2idm=19 MiB, t=2, p=119 MiB32 byte-
PBKDF2HMAC-SHA-256, 600000 iterazioni~032 byte-
Tabella dei parametri (Password Storage Cheat Sheet di OWASP, minimi 2023)
AlgoritmoMinimoNote
Argon2idm = 19 MiB (19456 KiB), t = 2, p = 1preferito; memory-hard
scryptN = 214, r = 8, p = 1memory-hard (16 MiB al minimo)
bcryptcosto = 10solo fattore di lavoro; limite di 72 byte per la password
PBKDF2-HMAC-SHA256600000 iterazionisolo iteration-hard — favorevole alle GPU, ultima scelta
I valori predefiniti di questa pagina sono pari o superiori a ogni minimo. Per la produzione scelga prima Argon2id, poi scrypt o bcrypt se non è disponibile, e PBKDF2 solo per motivi di conformità FIPS.
Interoperabilità con PHP — password_hash($pw, PASSWORD_BCRYPT) produce $2y$10$...: lo incolli in Verifica con la password candidata e questa pagina risponde esattamente come farebbe password_verify(). Anche l'output di PASSWORD_ARGON2ID ($argon2id$v=19$m=65536,t=4,p=1$...) viene verificato. Vengono analizzate anche le stringhe PHC di passlib, django-argon2 e del wrapping crypto.scrypt.
Autotest
Riesegue il motore della pagina sui vettori pubblici: la suite di test crypt_blowfish per bcrypt, le stringhe scrypt e Argon2id generate da node/OpenSSL, i vettori PBKDF2 della RFC 6070 e il set pubblico SHA-256, più prove di andata e ritorno generazione-verifica in ogni algoritmo e test negativi (una password errata deve fallire, le stringhe malformate devono essere rifiutate). Nulla viene inviato da nessuna parte.
Hashing delle password spiegato da zero
In una frase: un hash di password è deliberatamente lento (e preferibilmente avido di memoria), così che rubare il database non permetta a un attaccante di provare miliardi di ipotesi al secondo — l'obiettivo opposto di un hash veloce come SHA-256, che è progettato per la velocità.
Perché non applicare semplicemente SHA-256 alla password?

SHA-256 su una GPU moderna gira a miliardi di ipotesi al secondo. Una password di 8 caratteri ha molto meno di 1013 combinazioni — ore di tempo GPU, minuti su un sistema grande. Le funzioni di hashing delle password (KDF) rispondono con parametri di costo: bcrypt ripete il suo nucleo 2costo volte, PBKDF2 itera HMAC centinaia di migliaia di volte, scrypt e Argon2id richiedono inoltre megabyte di memoria per ogni ipotesi, così le GPU (veloci ma povere di memoria per core) perdono il vantaggio. Un sale — casuale, memorizzato in chiaro dentro la stringa dell'hash — impedisce le tabelle arcobaleno precalcolate e obbliga a calcolare ogni ipotesi da capo per ogni utente.

I quattro algoritmi di questa pagina
AlgoritmoAnnoRobustezzaFormato della firmaAttenzione a
bcrypt1999CPU (2costo configurazioni della chiave)$2b$12$ + sale di 22 caratteri + hash di 31 caratterilimite di 72 byte per la password (tutto ciò che supera i 72 viene ignorato in silenzio); il byte NUL termina la password nell'implementazione C originale
PBKDF22000 (RFC 2898/8018)CPU (iterazioni)$pbkdf2-sha256$i=600000$ + sale + hash (stile passlib)nessun costo di memoria — le GPU e gli ASIC lo adorano; è regolabile solo il numero di iterazioni
scrypt2009 (RFC 7914)CPU + memoria (128·N·r byte)$scrypt$ln=14,r=8,p=1$ + sale + hashN deve essere una potenza di due; la memoria cresce linearmente con r
Argon2id2015 (vincitore PHC, RFC 9106)CPU + memoria (m KiB, t passaggi)$argon2id$v=19$m=19456,t=2,p=1$ + sale + hashArgon2i (indipendente dai dati) contro Argon2d (dipendente dai dati) contro Argon2id (ibrido) — scelga sempre id a meno che non sappia perché no
Robustezza in memoria contro robustezza di calcolo

Una GPU ha migliaia di core, ma ogni core ha accesso solo a poca memoria veloce. Una KDF che richiede 19 MiB di working set per ogni ipotesi limita l'attaccante a tante ipotesi parallele quanti blocchi da 19 MiB di memoria possiede — ecco perché Argon2id a 19 MiB può essere più forte in pratica di bcrypt con costo 15, nonostante richieda meno tempo reale sul suo portatile. PBKDF2 non ha risposta a questo: il suo unico parametro è il numero di iterazioni, e il silicio scala quello linearmente.

Lettura di una stringa PHC

Il formato modular-crypt / PHC è autodescrittivo: in $argon2id$v=19$m=19456,t=2,p=1$ICEiIyQlJicoKSorLC0uLw$WTGpK4hf... i campi sono algoritmo, versione, parametri (m = memoria in KiB, t = passaggi, p = corsie), sale in base64, hash in base64. bcrypt precede lo standard e usa una propria forma compatta: $2b$ variante, 12 costo, poi sale e hash nell'alfabeto base64 personalizzato di bcrypt (./A-Za-z0-9). La verifica di questa pagina accetta tutte queste forme e mostra i campi analizzati — incolli un hash qualsiasi che trova e veda in cosa si scompone.

Errori comuni
  • Hash veloce per le password. Le colonne delle password con MD5/SHA-1/SHA-256 cadono sotto le GPU di uso comune a miliardi di ipotesi al secondo. Usi il Generatore di hash per file e dati; usi gli algoritmi di questa pagina per le password.
  • Condividere un sale. Un unico sale per tutti gli utenti significa che password uguali hanno hash uguali e le tabelle arcobaleno tornano utili. Ogni hash qui riceve un nuovo sale casuale di 16 byte.
  • Ignorare i 72 byte di bcrypt. "a"*100 e "a"*72 producono lo stesso hash — la coda viene eliminata. Questa pagina avvisa nella casella di input quando la password supera i 72 byte. Argon2 non ha un limite del genere.
  • Confrontare gli hash con == nel proprio codice. La verifica deve essere a tempo costante; il motore della pagina lo fa internamente (ricalcola e confronta i byte memorizzati), ma se copia l'approccio, usi un confronto a tempo costante.
  • Calibrare i parametri su una macchina di sviluppo veloce. Punti a circa 250–500 ms di hashing sull'hardware mediano dei suoi utenti di produzione, non sulla sua postazione di lavoro. Il pulsante Confronta mostra ciò che questo browser sperimenta davvero.
  • Ricalcolare l'hash a ogni controllo di accesso. Verifichi per prima cosa; ricalcoli l'hash (ad esempio per alzare il costo) solo dopo una verifica riuscita, e memorizzi la nuova stringa. La funzione PHP password_needs_rehash() esiste proprio per questo.
FAQ

Quale devo scegliere? Argon2id con almeno i minimi OWASP. Se il runtime non lo offre: scrypt, poi bcrypt (con un costo tale che l'hashing richieda ≥250 ms). PBKDF2 solo dove la certificazione lo richiede.

Perché nella stringa di output compare un sale casuale? Il sale non è un segreto — è memorizzato in chiaro dentro la stringa PHC di proposito, così la verifica richiede solo la stringa e la password candidata. Il suo compito è l'unicità, non la segretezza.

La variante conta ($2a$ / $2b$ / $2y$)? Per le password ASCII producono hash identici; $2a$ è l'originale degli anni Novanta, $2b$ ha corretto un raro bug di estensione del segno (2014), $2y$ è il marcatore di PHP che indica che la correzione è presente. La verifica accetta tutti e tre.

Quanto deve durare un hash? Circa 250–500 ms per accesso su hardware server. Sotto i 100 ms il cracking offline costa poco; oltre 1 s gli utenti si lamentano prima che la sicurezza migliori.

Posso verificare un hash prodotto altrove? Sì — lo incolli e indichi la password candidata. Formati noti: password_hash di PHP (bcrypt $2y$ e Argon2id), passlib di Python, l'hasher argon2 di django e il formato stringa scrypt usato dallo strumento scrypt di Tarsnap.

Cosa fa il pulsante "confronto"? Calcola l'hash della password attuale una volta con ciascun algoritmo ai parametri predefiniti della pagina e riporta il tempo reale in questo browser — un'idea delle differenze di costo, non una misura rigorosa.