Ho seguito questo utilissimo post di Thomas . Il mio caso d'uso è leggermente diverso. Sto sviluppando un'applicazione mobile che richiede la memorizzazione di alcuni dati sensibili sul dispositivo in un file SQLite. Sto usando SQLCipher per crittografare il file. La chiave di crittografia è basata su una passphrase di 10 caratteri (almeno una maiuscola, una minuscola, un simbolo e un numero) immessa dall'utente alla prima autenticazione su quel dispositivo. SQLCipher utilizza internamente PBKDF2 per generare la chiave di crittografia. Come per la Pubblicazione NIST l'entropia per questa passphrase è di circa 28 bit.
Quindi, secondo la formula in post di cui sopra:
v * 2n-1 >> f * p
v: Time required to compute derived key(DK) using one candidate pass-phrase using PBKDF2 function.
n: Entropy of the pass-phrase in number of bits.
2n: Total possible combinations using n bits.
2n-1: Average of 1 and 2n. The average number of candidate pass-phrases to be tried before actual pass-phrase is cracked.
f: Factor representing the computational power available to attacker relative to the system that ‘v’ was calculated on.
p: Patience of the attacker in terms of time.
p esce a 7,77 giorni, usando f = 200 (attaccante con 200 volte la potenza di calcolo) e usando 1 secondo per una derivazione di chiave. Come menzionato sopra, n = 28.
Ora veniamo alle mie domande:
- Che cos'è una stima realistica per f. So che nessuno può trovare un valore esatto, ma stime come il caso peggiore, caso medio, ecc. Sarebbero utili.
- La pubblicazione NIST di cui sopra suggerisce anche l'uso del dizionario insieme alle regole di composizione per garantire password più forti. Ho scaricato dizionari di password qui. Ora voglio sapere cosa significa la pubblicazione NIST con le trasformazioni delle parole del dizionario? Significa che se il dizionario contiene la parola "rock" dovrei disabilitare tutte le pass-phrase che contengono rock ? Quindi respingi
rock@Ston3eanche se sembra una password complessa. - Voglio usare pepe, ecco come sto pensando di usarlo. La passphrase viene immessa in PBKDF2 e
[random-salt(256bit)+pepper(256 bit)]è il sale per l'operazione. Diverse migliaia di iterazioni. Quindi invia l'hash risultante a SQLCipher che esegue 64000 iterazioni di PBKDF2 con 128 bit di sale per raggiungere la chiave di crittografia. C'è qualche problema con l'uso sopra suggerito di pepe e PBKDF2? - Uno dei miei colleghi ha suggerito di non archiviare la frase d'accesso con hash in un punto qualsiasi del disco. Piuttosto fare una query SQLite per recuperare alcune informazioni utente dal database (queste informazioni sono comunque necessarie e quindi nessun sovraccarico). SQLCipher darà un errore se la frase inserita è sbagliata dal momento che la chiave di crittografia generata sarà anch'essa errata e decifrata i dati di SQLite non avrà alcun senso (non correttamente formattato come previsto da SQLCipher). Il vantaggio che vedo in questo approccio è che ora la passphrase con hash non è memorizzata come è, ma le sue informazioni sono ancora distribuite nei dati SQLCipher. Quindi ora l'autore dell'attacco non può copiare il valore hash da un file e incollarlo nel suo codice ed eseguire un attacco di dizionario offline. Lui o lei può ancora copiare il file SQLite sul suo computer, ma ora per verificare la passphrase, un utente malintenzionato dovrà eseguire query sul database o almeno convalidare il database in qualche modo. La mia ipotesi è che, mentre le GPU sono veloci nel calcolare gli hash, non possono eseguire queste operazioni con la stessa efficienza. Quindi l'idea è di rallentare l'attaccante introducendo operazioni per le quali il suo hardware non è ottimizzato. La mia ipotesi è corretta?