Quanto conta il numero di iterazioni PBKDF2 sconosciuto per migliorare la sicurezza?

Non aggiungerebbe abbastanza sicurezza per importare. Significa semplicemente che l'attaccante deve confrontarsi con l'hash memorizzato dopo ogni iterazione della funzione PBKFD2, piuttosto che una volta dopo il conteggio (noto). Poiché un confronto è molto più veloce di un'iterazione (per qualsiasi ragionevole funzione di hash sottostante), ciò non rallenta in modo significativo l'aggressore.

Un problema un po 'più sottile è che l'attaccante deve giocare a indovinare la priorità con dove investire i suoi cicli. Se esegue il suo dizionario di password di base attraverso 1.000 iterazioni e non ottiene alcun risultato, dovrebbe andare in un dizionario più grande o estendere a 2.000 iterazioni? In pratica, probabilmente alternerà le espansioni di ricerca fino a quando non avrà un successo. Nota che se il suo programma di ricerca è scritto per supportare questo (non so se ce ne sono, ma è certamente possibile e il codice sorgente è disponibile), può salvare tutti i risultati intermedi dopo ad es. 1.000 iterazioni, quindi quando si estende a 2.000 iterazioni esegue solo il calcolo per altre 1.000 iterazioni.

Non appena l'aggressore trova una corrispondenza (la password più debole nel database), intuisce immediatamente che tutte le altre password hanno lo stesso conteggio e torna all'attacco standard. (Si noti che se si variano i conteggi tra i conti, si dovrà memorizzare il conteggio insieme all'hash, il che significa che quando ruba il database dell'hash avrà anche i conteggi e questo è tutto moot.)

BTW, il termine generale per cose come questa (elementi segreti dell'algoritmo di hash che sono gli stessi per tutti gli utenti, e quindi non devono essere memorizzati insieme agli hash) è "pepe". È un concetto utile (purché tu abbia un modo per memorizzare il valore del pepe che non verrà solo rubato insieme agli hash), ma questo non è un buon modo per iniettare il pepe nell'algoritmo di hash.

Un conteggio dell'iterazione nascosto non aggiungerà molto alla sicurezza, per due motivi:

• Il sistema che normalmente utilizza PBKDF2, ad es. per decifrare il file, deve conoscere il conteggio delle iterazioni. Potrebbe fuoriuscire, ad es. misurando il tempo impiegato da quel sistema per elaborare un file in arrivo; quindi potrebbe non essere così segreto. Inoltre, è improbabile che il conteggio dell'iterazione sia considerato parte della password, piuttosto come parte della configurazione : sarà scritto in un file di configurazione, forse definito in un documento di specifiche, o scambiato tramite e-mail ... Viceversa, se il conteggio delle iterazioni è considerato parte della password da tutte le parti e protetto come tale, allora la sicurezza almeno altrettanto buona (e probabilmente migliore) si otterrebbe semplicemente aggiungendo quel conteggio alla password (come stringa).

• Se guardi PBKDF2 , vedrai che calcolando l'output per il conteggio di iterazione c implica anche calcolare l'output per i conteggi di iterazione c-1 , c-2 ... ottieni tutti questi "gratuitamente" poiché questo è solo un grande XOR tra molti valori pseudocasuali, e nessuno di loro dipende dal numero voluto di iterazioni (altrimenti avrebbe potuto essere altrimenti, ma PBKDF2 è stato definito in questo modo). Provare un output PBKDF2 è in media meno costoso del calcolo della successiva iterazione: un'iterazione di PBKDF2 / SHA-1 per un output a 256 bit comporta due chiamate HMAC / SHA-1, quindi quattro invocazioni SHA-1, mentre "provare "una chiave significa decodificare il primo blocco con AES-256 e vedere se il risultato ha un senso; provare una chiave AES-256 è meno costoso che calcolare un elementare SHA-1, per non parlare di four elementare SHA-1. Ne consegue che "nascondere" il conteggio delle iterazioni rallenta un attacco di forza bruta di almeno il 25%, che non è nulla di sorprendente.