Ho cercato di cercare la risposta, ma l'ultima che ho trovato è stata superata di tre anni. Quindi quali sono i fattori di costo scrypt raccomandati per il 2016?
In generale, utilizza il fattore di costo massimo che è sopportabile dal punto di vista delle prestazioni. Vorrei creare un'applicazione di riferimento che sia il più vicino possibile a ciò che l'applicazione fa e scoprire il fattore di costo sull'hardware di produzione che ti dà il ritardo massimo tollerabile.
Nella maggior parte dei sistemi, cerco un ritardo da 10 a 20 ms. Supponiamo che il tuo attaccante abbia un hardware che è, ad esempio, 1000 volte più potente del tuo (il che non è irragionevole, dato che lo scrypt non può essere accelerato dalla GPU), può provare a supporre 10 5 al secondo. Per una password alfanumerica di 10 caratteri, vale 26 10 password, o circa 10 14 ipotesi. Ciò richiederebbe 10 9 secondi o 31 anni. Mi sembra accettabile.
Se vuoi usare ritardi ancora più alti, ricorda che scrypt è una memoria difficile. Ciò significa che utilizza un lotto (relativo) di memoria, nell'ordine dei megabyte, per ciascuna verifica, quindi avere molti di questi in esecuzione in parallelo potrebbe essere più un risultato di prestazioni rispetto alla potenza di elaborazione assoluta richiesta.
Dai un'occhiata a Security.stackexchange.com "Numero di iterazioni consigliato quando usi PKBDF2-SHA256?" per una buona analisi dello stesso argomento su PBKDF2.
Leggi altre domande sui tag passwords password-management hash scrypt