Salt, IV e Key sono necessari quando si crittografa la password in un database usando AES? Se sì, come dovrebbero essere usati?

7

Immagina di avere un sito Web con account utente. Voglio autenticare gli utenti, quindi ho bisogno di sapere se la password che forniscono corrisponde a quella memorizzata nel mio database. Per proteggere le password da occhi indiscreti, voglio offuscarle, decido di utilizzare AES in modalità CBC per farlo.

So che non dovrei usare AES-CBC per farlo, e probabilmente dovrei usare un algoritmo di hashing invece di uno di crittografia, ma per favore ignora questo fatto. Mi aiuterà a capire meglio le cose se lo fai.

Quando si crittografa la password dell'utente per memorizzarla nel mio database usando AES-CBC, devo usare una chiave, una IV e una Salt? Qualunque cosa ho bisogno di usare, come sarebbero usati esattamente?

Fornirò un esempio per spiegare meglio il mio problema:

A user with username "bob" signs up with the password "mypass"

I need to decide what is the safest way to obfuscate this password using AES-CBC.

Right now I think to do this I need to generate a 16-byte salt using a CSPRNG[1]. Than I must prepend the salt with the user password: salt+"mypass". Than I must encrypt salt+"mypass" using AES-CBC which I will use a hardcoded 256 bit key and a randomly generated IV of 16 byte.

Effectively I have: AesEncrypt(salt+"mypass", GenerateIv(), Key)

Dato questo esempio, ho alcuni punti che mi confondono.

1) L'IV casuale che sto passando ad AES avrà l'effetto che nessun "Mypass" dà lo stesso testo cifrato. Questo non rende la salatura ridondante, perché il punto del sale è di impedire che due testi cifrati del "bypass" siano identici?

2) Inversamente, potrebbe essere che la IV sia ridondante, e potrei semplicemente passare allo zero IV o alla costante IV dato che sto salendo le mie password?

3) Dire che IV e il sale non sono ridondanti, perché in qualche modo leggo senza capire veramente che l'IV è XORed ma non il sale, rendendo entrambi utili. È sufficiente che io salti in modo appropriato semplicemente anteponendo "mypass" con il sale?

4) In qualche modo dovrei usare il sale per ricavare la chiave che userò per crittografare "mypass" con AES? O lo sto facendo semplicemente usando un tasto hardcoded?

5) Cosa dovrei memorizzare nel mio database? Se il sale, il iv e il testo cifrato sono tutti archiviati in singole colonne, o dovrebbero essere combinati in qualche modo insieme, in tal caso, è sufficiente una semplice concatenazione, oppure devono essere combinati con una funzione speciale?

6) Ho sbagliato completamente e, in caso affermativo, cosa dovrei fare invece?

Grazie.

=============

[1] generatore di numeri pseudo casuali crittograficamente sicuro

    
posta Didier A. 07.03.2014 - 22:20
fonte

2 risposte

1

Hai ragione nel senso che sale e IV sono ridondanti: entrambi proteggono dallo stesso tipo di attacco (scoprendo che due account hanno la stessa password), e lo fanno nello stesso modo (facendo le rappresentazioni crittografate) della password differiscono).

    
risposta data 08.03.2014 - 08:15
fonte
7

When encrypting the user password to store it in my database using AES-CBC, do I need to use a Key, an IV and a Salt? Whatever I need to use, how would they be used exactly?

L'IV viene utilizzato per inizializzare la prima matrice a 16 byte dello schema di crittografia AES-CBC. È XORed con il primo 16 byte del messaggio. Ciò significa che, se IV è costante, lo stesso messaggio emetterà sempre lo stesso testo cifrato. D'altra parte, se la IV è diversa su ogni esecuzione di crittografia dello stesso messaggio, a causa dello XORing della IV con il primo blocco, il testo cifrato sarà sempre diverso, poiché il risultato dello XOR sarà diverso. IV è una parte inerente di AES-CBC e dovrai sempre usare una IV, la scelta è se questo IV sia costante o meno.

Il Salt è un messaggio casuale che anteponi al messaggio reale in modo che su ogni codifica del messaggio reale, in realtà stai codificando un messaggio dall'aspetto diverso (sale + messaggio reale) che risulterà in un testo cifrato differente. Questo è normalmente usato per algoritmi di hashing, al fine di ottenere un hash diverso su ogni esecuzione di hashing dello stesso messaggio.

Non è necessario utilizzare un sale con AES-CBC, perché l'IV sta già avendo l'effetto che il sale è progettato per avere. Ma se vuoi usare un sale, puoi farlo, ed ecco cosa succederebbe. Supponiamo che tu avessi un valore di 16 byte, che sarebbe stato aggiunto al tuo messaggio, quindi avresti (sale + messaggio) come input da crittografare da AES-CBC. Essendo 16 byte, il tuo sale si adatterebbe nel primo blocco di AES-CBC, sarebbe XORed con la IV e di conseguenza avresti (sale XOR iv). Questo risultato di (sale XOR iv) sarebbe quindi utilizzato come IV per il secondo blocco, che in questo caso sarebbe il primo byte del messaggio reale.

Pertanto, nel caso di AES-CBC, l'uso di un sale ha solo l'effetto di un'ulteriore elaborazione sulla parte IV. Se il tuo IV è costante, sale con XOR, risultando in una nuova IV del secondo blocco diverso per ogni esecuzione della crittografia, anche se la IV è costante.

Quindi, in conclusione, è meglio usare solo un IV casuale e non usare affatto un sale. O usare una IV costante e avere un sale casuale (ma attenzione per questo, vai a vedere # 2 sotto per i dettagli). Entrambe avranno lo stesso effetto, ovvero generare un testo cifrato diverso su ogni esecuzione di crittografia dello stesso messaggio.

1) The random IV I am passing to AES will have the effect that no two "mypass" gives the same ciphertext. Doesn't this make the salting redundant, because the point of the salt is to prevent two ciphertext of the "mypass" to be identical?

Sì, lo fa. L'IV e il sale hanno lo stesso effetto e aiutano a proteggere dagli stessi attacchi. Nota che, affinché il sale abbia lo stesso effetto, deve essere considerato il pensiero corretto nella sua implementazione, vedi il n. 2 sotto per maggiori dettagli.

2) Inversely, could it be that the IV is redundant, and I could just pass in the zero IV or a constant IV since I am salting my passwords?

Non così veloce. Un sacco di cose devono essere messe insieme correttamente affinché questo sia vero. A seconda della modalità di AES, potrebbe non essere sempre vero che la salatura risulterà nel comportamento desiderato. La lunghezza del sale e il modo in cui lo si concatena con il proprio messaggio devono anche essere corretti, l'aggiunta potrebbe portare a problemi per le password lunghe, ad esempio. Pertanto, è meglio utilizzare l'AES come si pensava, cioè utilizzare un IV casuale e senza sale.

3) Say the IV and the salt are not redundant, because somehow I read without really understanding that the IV is XORed but not the salt, making both useful. Is it enough for me to properly salt to simply prepend "mypass" with the salt?

L'IV è XORed con il primo blocco di AES in modalità CBC da crittografare. Se usi un sale, il sale sarà XORed con IV nel primo blocco, e questo (IV xor Salt) diventerà effettivamente l'IV del secondo, che con un sale di 16 byte sarà il tuo messaggio reale da crittografare .

4) Am I somehow supposed to use the salt to derive the key that I will use for encrypting "mypass" with AES? Or am I doing it right by simply using a hardcoded key?

Non dovresti mai derivare la chiave dal sale. Il sale non è segreto, e quindi, se lo facessi, la chiave sarebbe facilmente reperibile dal sale non segreto. Mi stavo confondendo con la crittografia basata su password, in cui si utilizza una funzione di derivazione della chiave per derivare la chiave da una password segreta.

5) What am I supposed to store in my database? Should the salt, the iv and the ciphertext all be stored in individual columns, or should they be somehow combined together, if so, is simple concatenation enough, or they must be combined with a special function?

Da quanto ho capito, non importa, purché tu sappia come recuperarli. Puoi utilizzare una colonna diversa o unirle in una in qualche modo.

6) Am I completely wrong and if so, what should I do instead?

Fondamentalmente, sto usando AES-CBC come funzione di hashing. Dove normalmente la chiave a 256 bit di AES significa che è molto difficile da applicare alla forza bruta, questo scavalca il fatto che qui puoi forzare la combinazione del messaggio, poiché il messaggio è una password, è probabile che sia molto più corto di 256 bit a bruto forza.

L'altro problema è che, essendo un algoritmo simmetrico, se un hacker compromette il server e ottiene la chiave, non ha nemmeno bisogno di forza bruta, attacco dizionario, tavolo arcobaleno o qualsiasi altra cosa, può solo decifrare tutto le password.

    
risposta data 12.03.2014 - 21:51
fonte

Leggi altre domande sui tag