Ho copiato una funzione che implementa l'algoritmo di hash PBKDF2 in PHP. La funzione richiede la quantità di tempo che desidero che esegua il ciclo per produrre un hash.
Ora, mi chiedo, quale sarebbe un numero di iterazioni ragionevolmente alto che garantisce un hash molto sicuro, mentre allo stesso tempo non fa rallentare il server fino alla scansione.
Quindi la saggezza di Wikipedia è che 1.000 iterazioni erano il numero atteso nell'anno 2000. La legge di Moore dice che il potere raddoppia ogni 18 mesi. Ciò vale (aww, non possiamo usare MathJAX qui) 2 ^ (11 / 1.5), o approssimativamente un fattore di 160. Con questa teoria, dovresti usare qualcosa nel campo di gioco di 160.000 iterazioni.
... ma in realtà, basta un punto di riferimento. Calcola quanti accessi al secondo vuoi che il tuo server gestisca e imposta di conseguenza il numero di iterazioni. Ricorda che puoi aumentare il numero di iterazioni nel tempo più facilmente di quanto tu possa ridurle (riduzione solo all'accesso), quindi riprendi un po 'in modo prudente.
Bene, l'hai detto tu. Il conteggio corretto è esattamente il conteggio che "non fa rallentare il server fino alla scansione". Vuoi che sia il più alto possibile, dato l'hardware che utilizzi e il carico medio previsto. Come ha detto @Jeff, si tratta di un punto di riferimento.
L'intero concetto consiste nel rendere lento il processo di hashing della password per l'utente malintenzionato. Questo lo rende lento per chiunque, incluso te, quindi non puoi farlo come vorresti. Il principio al lavoro qui è che la tua nozione di costo, e quella dell'attaccante, non sono esattamente proporzionali: un aumento di costo di 1000x è "gratuito" per te se significa che spenderai 1ms anziché 1μs per autenticare un utente, considerando trasformare un attacco di 1 ora in un attacco di 6 settimane è certamente non gratis per l'attaccante.