Come dovrei scegliere un fattore di difficoltà per la mia funzione di hashing della password?

Sfortunatamente, l'ampia varietà di hardware impedisce la costruzione di tabelle come quella che si desidera a meno che non si effettui prima un rilevamento di tutte le architetture hardware esistenti e le migliori implementazioni bcrypt / scrypt / PBKDF2 per tale architettura. Anche il tavolo nell'articolo scrypt non è quello che vuoi: non ti dice quanto costerebbe per un attaccante; indica quanto sarebbe costato a un utente malintenzionato con l'hardware e il software a cui pensava lo scrypt designer quando scriveva l'articolo .

Tali stime non si adattano bene, a proposito. Se fossi un attaccante di fronte a un costo di attacco stimato in 10 miliardi di dollari con l'hardware disponibile, per prima cosa investirò un miliardo di dollari nella costruzione di un sistema basato su ASIC personalizzato che sarebbe più veloce per quel lavoro. Un PC è buono a fare gli accessi RAM pseudocasuali, ma non a l'hardware migliore possibile per quello, se non altro perché ci sono molti altri componenti in un PC, che sono inutili per un attacco.

Almeno, per PBKDF2, poiché il calcolo esegue il mapping alla funzione di hash sottostante senza problemi di accesso alla memoria, è possibile utilizzare i benchmark delle funzioni hash esistenti per ottenere un'idea (ad esempio questi ).

Detto questo, non tutto è perduto. Non otterrai stime accurate dei costi di attacco, ma ciò non significa che tutto ciò che puoi fare è lamentarti, avvizzire e morire. Un primo metodo pragmatico è impostare il conteggio delle iterazioni più alto possibile : impostarlo sul valore più alto che non rallenta in modo intollerabile il normale processo di accesso. In questo modo, non saprai se la tua sicurezza è buona , ma sarà buona come può ottenere . Che è una consolazione.

Il resto del lavoro sarà dal lato degli utenti. Dopo tutto, il fattore di difficoltà nell'hash delle password è lì per contrastare la legge di Moore. Tuttavia, nella migliore delle ipotesi, questa è una corrispondenza tra entropia della password e la pazienza dell'attaccante :

• Il vantaggio dell'attaccante è che è più ricco, può acquistare hardware dedicato ed è paziente : può permettersi di trascorrere un'ora, forse un giorno, per craccare una password di alto valore; mentre l'utente non tollererà l'attesa per più di un secondo durante l'accesso.
• Il vantaggio del difensore è entropia della password .

Contabile per un fattore di efficienza di 1000 per l'attaccante (hardware dedicato, più gettoni in esso) e un fattore di pazienza di 86400 (l'attaccante vuole riuscire entro un giorno, l'utente non aspetterà più di un secondo), quindi l'entropia della password deve superare 86 milioni (ovvero un po 'più di 26 bit) se il difensore è vincere la partita. Per aumentare l'entropia della password, c'è solo un modo: educare, educare ed educare di nuovo. Non cercare di applicare le "regole per la password", ma piuttosto antagonizzare gli utenti anziché creare password complesse. Invece, fornire un pulsante non obbligatorio generatore di password, che produce password con, ad esempio, 40 bit di entropia, e spiegare agli utenti che usare il pulsante sarebbe un'ottima idea.

Usando l'hardware di destinazione, selezionerei un costo che fa sì che l'algoritmo impieghi circa 1/10 di secondo. Implementare un ritardo dopo i tentativi di accesso falliti. Non sarà economicamente conveniente forzare con forza qualsiasi password che non sia stata scelta in modo terribile (ad esempio nome utente, nome del sito, "password"). Il valore effettivo che scegli dipende dall'hardware di destinazione.

La velocità dell'algoritmo
1. non ha importanza se le password sono deboli.
2. se la password è in un dizionario, sei quasi istantaneamente avvitato
3. se la password è generata da una regola che è inclusa con JtR o Hashcat, sei fottuto un po 'più tardi;)

Oltre a questo, quanti utenti / password stai memorizzando? Se si sta proteggendo solo un account (si pensi a un server con solo l'account di root su di esso), quindi la salatura è discutibile.

Quanto spesso sei costretto a cambiare le password? Se la difficoltà della password costringerà l'attaccante a un set completo di caratteri, password bruteforce lunga, allora puoi fare un'approssimazione decente: NumberOfCombos / CrackSpeed = TimeToCrack

Quindi se hai un ASCII stampabile di 6 caratteri, completamente casuale, (95 simboli) che puoi decifrare 100 al secondo, hai 95 ^ 6/100 = 233 anni per strappare l'intero spazio delle chiavi.

Tuttavia, se stai usando un algo veloce (la mia GPU rompe un singolo MD5 non salato a 8 miliardi / sec) e lanciando hardware decente, puoi craccare l'intero spazio tasti di 6 caratteri in circa 90 secondi. Andando alla lunghezza 7 con lo stesso set di caratteri si allunga il tempo di crackare a > 2 ore e la lunghezza 8 si estende a 9 giorni. Quindi, se cambi le tue password ogni 90 giorni, questo dà all'aggressore un sacco di tempo per craccare e usare quella lunghezza 8, la password di charset 95.

La regola è semplice, più grande è il tuo charset e più tempo fai la password, lo spazio delle chiavi crescerà a un ritmo ridicolo. I moderni hardware e software rendono il cracking molto veloce, ma puoi mitigare la minaccia con sali / alghe. Il vero killer è quando non hai forzato l'attaccante in uno scenario bruteforce. Dizionari / regole / permutazioni / attacchi combinati multi-parola sono estremamente efficienti nel trovare password non casuali.