Sarei felice di spiegare ulteriormente i miei commenti: -)
Sfortunatamente non è una spiegazione semplice.
For a bcrypt-hashed password, how much of an advantage would this give the attacker? Can this be quantified?
Quantificare questo sarà difficile dal momento che indovinare al runtime di un algoritmo è difficile, specialmente se l'hacker è autorizzato a creare chip specializzati per il lavoro.
Quindi nessuna matematica elaborata :-( ma posso ancora dare una risposta basata sull'intuizione;
bcrypt è progettato per le password di hashing in un modo che è solido per gli attacchi di dizionario offline, il che significa che, tra le altre cose, è lento . Lento significa che un utente malintenzionato che esegue la forzatura bruta deve eseguire più calcoli per ipotesi, e quindi non può fare tante supposizioni al secondo. Oppure, in termini economici, la quantità di denaro che un utente malintenzionato deve spendere in processori ed elettricità per rompere le password quando si utilizza una bella funzione di hash lento.
Per illustrare il punto, questa tabella, tratta da un articolo di Colin Percival (riferimento completo in basso), mostra il costo stimato dell'hardware di cui avresti bisogno per crackare in modo affidabile un hash in un anno (nota che questo è il costo per il numero di processori dell'era del 2002 di cui avresti bisogno, ignora completamente i costi di elettricità, alimentazione, raffreddamento, ecc.)
Oracheabbiamostabilitocheilrallentamentoèbuonoechelebuonefunzionidihashsonolente,parliamodizxcvbn.
zxcvbnèpensatoperessereunjavascriptdohickycheesegueillatoclientsenzarallentarelapagina,quindiconfrontatoconPBKDF2,bcryptescrypt,èunfulmineo.
Perrispondereeffettivamenteallatuadomanda,immaginadiaverrubatoundatabasedipasswordincuiognirigaerasimileaquesta(cheèciòchecredo@ScottArciszewskistavadescrivendonelsuocommento qui ):?
username bcrypt_hash bgcypt_salt zxcvbn_score
happyfish23 IjZAgcfl7p92ldGxad68LJZdL17lhWy N9qo8uLOickgx2ZMRZoMye 32.827
Tipicamente un attacco a forza bruta prenderà una password dal suo dizionario, lo cancellerà e vedrà se l'hash corrisponde a quello nel database rubato, se lo fa allora ho crackato la tua password, altrimenti continuo a provare fino a trova quello che corrisponde. (Questo può essere fatto online uno alla volta come le password sono indovinate, o come una tabella arcobaleno pre-calcolata, ma in entrambi i casi, rallentare questa diminuzione costa tempo e denaro, specialmente perché è necessario un tavolo arcobaleno diverso per ogni combinazione alg + iteration_count salt )
Con l'accesso al database di cui sopra, potrei usare il punteggio zxcvbn come filtro; se i punteggi di zxcvbn non corrispondono, allora so già che non è la password giusta e non c'è motivo di perdere tempo nel calcolo di bcrypt. Quindi ho solo bisogno di calcolare bcrypt se zxcvbn corrisponde. Dato che zxcvbn è fondamentalmente gratuito, rispetto a bcrypt, non è irragionevole che un brute-forcer possa passare da 10 ipotesi / secondo a milioni di ipotesi / secondo usando questo trucco.
Per quanto riguarda la seconda parte della tua domanda:
Also, other comments mention that reducing the precision of the entropy reduces the attacker's advantage. Would storing only the score (0, 1, 2, 3, or 4) effectively eliminate the advantage?
Sì, ciò eliminerebbe in modo efficace il vantaggio. Il motivo per cui praticamente non rientra nella spiegazione sopra. Supponiamo che il database originale memorizzi un punteggio zxcvbn a 5 cifre e che le password nel dizionario brute-force siano distribuite uniformemente su punteggi zxcvbn (un presupposto terribile, ma rende la logica facile). Ci si aspetterebbe che i punteggi zxcvbn corrispondano a 1 / 100.000 delle volte, quindi è necessario calcolare un bcrypt ogni 100.000. Ma se invece memorizzi una versione di precisione inferiore della partitura, ad esempio {0,1,2,3,4} , allora sarai obbligato a calcolare bcrypt per ogni 5 ipotesi. Stai ancora dando all'autore dell'attacco un'accelerazione di ~ 5 volte, ma questo è WAAAYY meglio di un 100.000x di accelerazione.
RIFERIMENTO:
Percival, Colin. "Più strong derivazione della chiave tramite funzioni sequenziali di memoria difficile." Auto-pubblicato (2009): p. 14 (link al pdf)