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.