Il tuo punto di partenza

PBKDF2-HMAC-SHA-256

number of iterations desired = 1024

length of the salt in bytes = 16

length of the derived key in bytes = 4096

Algoritmo

Ok - PBKDF2-HMAC-SHA-256 è una scelta solida, sebbene se tu stia utilizzando qualsiasi moderna CPU a 64-bit, ti consiglio vivamente PBKDF2-HMAC-SHA-512, perché SHA-512 richiede 64 operazioni a bit che riducono il margine di vantaggio di un attaccante della GPU, dal momento che le GPU moderne non lo fanno anche a 64 bit.

Salt

16 byte di sale vanno bene, purché siano crittograficamente casuali e siano univoci per password. Le raccomandazioni normali sono nell'intervallo 12-24 byte, con 16 considerato abbastanza solido.

Output e iterazioni

4096 byte di output sono ACTIVELY BAD! SHA-256 ha una dimensione di output nativo di 32 byte. PBKDF2 / RFC2898 afferma che in questo caso, per prima cosa eseguirai 1024 iterazioni per ottenere il primo (a sinistra) 32 byte, quindi altre 1024 iterazioni per i successivi 32 byte e così via per 128 volte in totale per ottenere i 4096 byte di output richiesti.

Quindi, hai fatto 131072 iterazioni in totale e hai ottenuto 4096 byte di output. L'hacker eseguirà 1024 iterazioni in totale e confronterà i 32 byte di output con i primi (a sinistra) 32 byte dell'output - se sono uguali, hanno indovinato correttamente! Hai appena dato ad ogni attaccante un vantaggio di 128: 1!

Invece, se sei soddisfatto della velocità, dovresti eseguire 131072 iterazioni con 32 byte di output - trascorrerai la STESSA quantità di tempo che sei ora (quindi è gratis!) e i tuoi attaccanti dovranno spendere 128 volte più tempo di adesso!

• NOTA: se ti sposti su PBKDF2-HMAC-SHA-512, puoi utilizzare fino a 64 byte di output e ogni iterazione impiegherà un po 'più di tempo.

Non ottieni mai più output per l'hashing della password rispetto all'output nativo della tua funzione hash, cioè 20 byte per SHA-1, 32 per SHA-256, 64 per SHA-512. Puoi opzionalmente memorizzare meno, ma non ti risparmia calcoli. Consiglierei di memorizzare almeno 28 byte di output (224 bit, ovvero due volte 112 bit, la sicurezza nominale di 3DES).

Nota che i valori della lunghezza dell'output sono pura emissione binaria - PRIMA di BASE64 o esagonali, se lo fai (personalmente, vorrei memorizzare il file binario grezzo - usa meno spazio e richiede una conversione in meno).

Il mio primo suggerimento è di utilizzare il meccanismo di memorizzazione password predefinito della piattaforma. Funziona come il password_hash di PHP, prendi tutte le preoccupazioni e gli svantaggi della memorizzazione delle password.

Supponendo che non puoi farlo, ti consiglio di usare bcrypt, o forse anche le funzioni di scrypt più recenti. bcrypt è più difficile da decifrare quando si usano operazioni parallele su una GPU. scriva la memoria delle tasse così come la CPU. Questa risposta spiega tutto questo è un grande dettaglio.

Supponendo che sei bloccato con pbkdf2 per qualsiasi motivo ...

Salt: in base alla risposta 2013 di Thomas Pornin, 128 bit o 16 byte sono sufficienti. I consigli di Crackstation sono 192 bit o 24 byte. Penso che ovunque in quell'intervallo sia sicuro. Personalmente, vorrei andare con i 24 byte come la lunghezza del sale (supponendo che non ti blocchi per generare dati casuali) non contribuisca veramente alle prestazioni dell'hash. Assicurati di utilizzare un CSPRNG per generare il sale.

Lunghezza della password: la risposta di Thomas Pornin raccomanda 12 byte, Crackstation 24. Di nuovo, tenderei ad andare con le dimensioni maggiori, ma penso che qualsiasi cosa in quell'intervallo sia sicura.

Iterazioni: il numero di iterazioni dovrebbe essere il numero che puoi tollerare. Quindi inizia a testare le prestazioni dell'hashing. Ho visto raccomandazioni per 0,05-0,10 secondi ma penso che quelle siano solo stime. Se hai risorse computazionali da risparmiare, forse puoi andare un po 'più in alto (troppo più alto rallenterà troppo l'autenticazione). Se sei scarso con risorse computazionali, vai più piccolo.

Riepilogo:

number of iterations desired        = max you can tolerate
length of the salt in bytes         = 16-24
length of the derived key in bytes  = 12-24

1. 8 byte salt va bene, perché è globalmente unico quando generato casualmente, e questo è lo scopo di un sale: unicità. Troppo grande non è un problema, quindi stimare il lato alto va bene, tranne che si spreca un po 'di spazio di archiviazione.

2. 32 byte andrebbe bene per una lunghezza chiave derivata (la maggior parte degli algoritmi di hashing genererà tra 16 e 64 byte, dove 64 è solo eccessivo). Il tuo valore di 4096 è decisamente eccessivo: spero davvero che tu abbia scambiato byte per bit lì!

3. Le iterazioni sono molto semplici: il maggior numero possibile sul tuo hardware. Se un login può richiedere fino a mezzo secondo, confronta quante iterazioni puoi fare prima che passi mezzo secondo. Nel 2018, 300 000 è un valore ragionevole per un server a bassa potenza (le CPU di fascia alta possono gestire più iterazioni).

Se stai usando un sistema sottodimensionato (ad esempio Raspberry Pi), potresti prendere in considerazione hardware diverso a seconda di come dovrebbero essere le cose sicure, o rendere il login più lungo. In genere, l'accesso viene effettuato solo una volta al giorno, quindi attendere 10 secondi potrebbe essere ragionevole in base ai propri obiettivi.