Cronologia delle password con PBKDF2

Da dove proviene il requisito "precedente 15"? Sembra improbabile che la sicurezza aumenti di molto: il mio primo passo sarebbe quello di ridurre questo se non proviene da requisiti legali, normativi, di settore o di controllo.

• Un utente malintenzionato che sta effettuando un attacco online non si noterà affatto
• Un utente malintenzionato con il tuo database PW che effettua un attacco offline contro solo le password correnti non si preoccuperà durante l'attacco
• Un'analisi complessa della notazione di pattern sulla parte degli attaccanti è troppo complessa per entrare qui, ma immagina un utente che usa football1, poi football10, football100, ecc. Lo schema è ovvio se hai qualche password, anche se football100000000 potrebbe non essere provato fino a quando non si è in grado di indovinare una password (se non del tutto, visto quante centinaia di migliaia di iterazioni si devono usare)

Si noti inoltre che provare N diversi valori PBKDF2 in una volta significa che è possibile utilizzare più core; Ad esempio, per 15 PBKDF2 viene eseguito a 1s ciascuno, se si dispone di 10 core, questo potrebbe richiedere un minimo di 2 secondi (10 nel primo secondo, 5 nel secondo secondo). Ti servirà lo stesso (o un po 'di più) tempo della CPU, però: attenzione.

Riducendo in modo significativo il tempo di esecuzione di PBKDF2 diminuisce , poiché l'autore dell'attacco deve eseguire meno lavoro nella stessa proporzione con meno lavoro. Se puoi permetterti di scegliere 1s di tempo CPU (presumibilmente per accessi poco frequenti o per una server farm molto potente), mantienilo! Ciò aumenterà drasticamente il carico di lavoro di un attaccante allo stesso livello che riduce il tuo; Non lo consiglio.

Se stai mirando a un secondo di lavoro su PBKDF2 per accesso, 15 utenti che effettuano l'accesso all'incirca nello stesso momento sono esattamente lo stesso carico di lavoro di 15 altre operazioni PBKDF2 salt uniche: assicurati di poterti permettere i tuoi attuali tempi target il carico di punta previsto per i prossimi 2-3 anni. Inoltre, con quale frequenza gli utenti cambieranno le loro password?

Un'altra alternativa:

• Non modificare il sale di un utente ogni volta.
  • Questa è non una grande idea, ma può essere eseguita e risolverà il tuo problema di prestazioni. Tuttavia, gli attaccanti offline con l'elenco completo delle password avranno 16 volte le possibilità di indovinare le password per ogni tentativo.
  • Solo cambiando il sale ogni 2 o 6 cambi di password finirebbe in una posizione intermedia - sarebbe meno grave se si hanno cambiamenti di password molto frequenti.

P.S. Sai che stai per ottenere utenti che usano P @ $$ w0rd1, P @ $$ w0rd2, P @ $$ w0rd3, P @ $$ w0rd ..., P @ $$ w0rd999, vero?

Che ne dici di questo: quando cambi le password, chiedi la vecchia password (lo fai comunque, giusto?) e poi oltre al test per vedere se la vecchia password corrisponde, RIPRISTA ANCHE la vecchia password usando un singolo iterazione. Dal momento che non è più valido non ti importa tanto di quanto sia facile croppare (perché il cracking non aiuta molto l'aggressore). E poi memorizzare la versione hash veloce nella tua cronologia.

A volte potresti non ottenere la vecchia password (diciamo se cambiata da un amministratore) quindi potresti voler mettere un marcatore nel tuo vecchio campo password per indicare come è stato sottoposto a hash, in quel modo il tuo sistema è compatibile con entrambe le varianti.

Ciò che Travis non ha detto è stato lo scopo generale dell'utilizzo delle vecchie password in primo luogo. Voglio dire, l'audit potrebbe richiedere, ma nessuno sta dicendo PERCHÉ è richiesto. Probabilmente è una cattiva idea. In generale, non aumenterà la sicurezza e, a parte i problemi di prestazioni, rischia di ridurre significativamente la riduzione della sicurezza se non viene eseguita correttamente. È molto più probabile che sia fatto in modo improprio che non correttamente.

Se lo scopo è quello di garantire una "catena di possesso" dell'account, ci sono altri modi per farlo, con una perdita di prestazioni molto ridotta.

Ecco un semplice esempio: se il tuo generatore di numeri pseudo casuali è buono in primo luogo, un XOR di un qualsiasi numero di sali dovrebbe essere esattamente casuale come qualsiasi singolo sale. Nessuna differenza crittograficamente.

Quindi potresti prendere tutti i sali per quell'utente (incluso quello corrente), XOR tutti insieme, e usarlo come sale effettivo durante la generazione o l'autenticazione della password corrente.

Che stabilisce una cronologia chiara e richiesta, non dovrebbe ridurre la tua sicurezza, XOR è estremamente veloce e hai ancora una sola chiamata a PBKDF2.