È corretto utilizzare hash SHA1 di password come salt quando si derivano la chiave di crittografia e IV dalla stringa della password?

Question

Sto utilizzando Rfc2898DeriveBytes per generare in modo sicuro la chiave di crittografia e il vettore di inizializzazione dalla password di stringa fornita dall'utente, da utilizzare con la crittografia simmetrica (ad esempio AesManaged).

Sto prendendo l'hash SHA1 della password come parametro salt su Rfc2898DeriveBytes. È ok? Se no, allora da dove dovrei prendere il sale? Avrò bisogno dello stesso sale quando decifro, giusto? Quindi devo conservarlo da qualche parte in chiaro - non protetto. Se devo conservarlo in modo sicuro, diventa semplicemente un'altra "password", vero?

void SecureDeriveKeyAndIvFromPassword(string password, int iterations, 
    int keySize, int ivSize, out byte[] key, out byte[] iv) 
{ 
    // Generate the salt from password: 

    byte[] salt = (new SHA1Managed()).ComputeHash(Encoding.UTF8.GetBytes(password)); 

    // Derive key and IV bytes from password: 

    Rfc2898DeriveBytes derivedBytes = new Rfc2898DeriveBytes(password, salt, iterations); 

    key = derivedBytes.GetBytes(keySize); 
    iv = derivedBytes.GetBytes(ivSize); 
} 

Ho visto usare il costante (hardcoded) sale e ho visto persone lamentarsi. Pensavo che ricavare il sale dalla password sarebbe stata l'idea migliore, ma non sono sicuro che questa sia una soluzione ottimale.

In breve, ho un file che deve essere crittografato e la stringa di password immessa dall'utente. Come uso correttamente Rfc2898DeriveBytes per derivare la chiave di crittografia sicura e IV?

Grazie.

EDIT:

Grazie per le vostre risposte. Ora capisco che lo scopo principale (forse solo?) Di Salt è rendere impossibile la generazione di tabelle arcobaleno - non è possibile pre-generare l'hash di "P @ $$ w0rd" perché avrà un hash diverso per ogni possibile valore salato. Lo capisco perfettamente, MA ... È davvero rilevante per la crittografia simmetrica? Non sto memorizzando l'hash ovunque, giusto? Quindi, anche se l'attaccante ha la tabella arcobaleno per tutte le possibili combinazioni di password, non può fare molto, giusto?

Quindi, la mia domanda ora è: C'è qualche vantaggio di usare il sale a caso in ogni operazione di cifratura, rispetto all'utilizzo di una password di derivazione (o hard-coded anche) sale, se utilizzato con algoritmi di crittografia simmetrica (come AesManaged of .NET)?

Answer 1

Un sale deve essere univoco per ogni password, che significa creare una password casuale per ogni password che si desidera hash. Il sale è non un segreto e può essere memorizzato in formato testo con il valore hash calcolato.

L'idea del sale è che un utente malintenzionato non può utilizzare un arcobaleno prefabbricato per ottenere le password. Avrebbe dovuto costruire un tale rainbowtable per ogni password separatamente, e questo non ha senso. È più facile usare la forza bruta, finché non trovi una corrispondenza.

C'è un esempio in MSDN in cui il sale viene ottenuto dalla sorgente casuale del sistema operativo . Questo è il meglio che puoi fare, per avere un salato sicuro, non scoraggiarlo dalla tua password.

Answer 2

Non so davvero cosa sia Rfc2898DeriveBytes ma posso dirti quanto segue: il sale non deve essere protetto. Ora, hai detto che hai visto persone lamentarsi di valori costanti e codificati per il sale, e chiunque abbia detto che è giusto. Il sale dovrebbe essere un valore casuale, mai costante, altrimenti il ​​suo scopo è sconfitto.

Capisci per cosa è usato il sale? Chiaramente no Usare l'hash come sale è una cattiva idea perché la password X sarà sempre salata con lo stesso valore Y, ancora una volta, sconfiggendo il suo scopo.

Answer 3

Le persone non amano i sali codificati in quanto sono accessibili a tutti gli sviluppatori del progetto (e possibilmente al pubblico nel caso di progetti open source o reverse engineering). Gli attaccanti possono quindi calcolare le tabelle arcobaleno per il tuo particolare sale e iniziare ad attaccare il tuo sistema.

Una buona scelta di valore salt è qualcosa che:

• è disponibile ogni volta che si controlla la password
• non cambia tra i controlli delle password
• è diversa per ogni (o quasi) i calcoli di password

Un nome utente sarebbe quindi una scelta decente, purché non possa cambiare. Oppure, generare un valore completamente casuale quando si crea l'utente per la prima volta e lo si memorizza come il sale, insieme ai dati dell'utente nel database.

Answer 4

Un sale è progettato per proteggere dagli attacchi multi-target rendendo ogni bersaglio si comporta in modo diverso. Le tavole arcobaleno sono solo una particolare incarnazione di attacchi multi-bersaglio, in cui lo sforzo computazionale è esaurito prima di ottenere gli obiettivi.

Ci sono situazioni in cui gli attacchi multi-target sono applicabili, ma le tabelle arcobaleno non lo sono.

Un esempio di questo: si supponga di utilizzare uno schema di crittografia autenticato con sicurezza semantica, come AES-GCM con nonce univoci. Ora hai ottenuto un milione di messaggi diversi crittografati utilizzando password diverse.

Se non si utilizza il sale, per verificare se una password applica a uno qualsiasi di questi, l'attaccante ha bisogno di una KDF operazione, e un milione di decrittazione operazioni. Se si utilizza un salt, l'attacker necessita di un milione di operazioni KDF e di un numero di un milione di operazioni di decodifica un milione di operazioni. Poiché il KDF è lento rispetto alla decrittografia, un attacco contro il primo schema è molto più rapido di un attacco al secondo schema.

Answer 5

Altri hanno già spiegato lo scopo del sale e perché possono essere informazioni pubbliche.

Un'ulteriore parte della risposta alla tua domanda: non ricava il sale dalla password stessa. Sarebbe molto simile allo svarione della programmazione che ha finito per esporre milioni di password dopo l'hack di Ashley Madison.

Il problema è che quando si utilizza la password per generare il sale, si sta essenzialmente rendendo la password disponibile in una seconda forma, e molto più facile da decifrare. L'attaccante può ignorare completamente l'output del PBKDF2 e invertire semplicemente il sale stesso. Questo è protetto solo con SHA1, che è già rotto.

A Ashley Madison, l'errore era simile. Le password sono state archiviate nel database principale utilizzando bcrypt e si ritiene che siano sicure. Ma poi qualcuno ha scoperto che le password per molti account erano effettivamente archiviate due volte e la seconda copia era protetta solo con MD5.