Stiamo costruendo un'applicazione di base che ha bisogno di crittografare SSN, DOB, ecc ...
L'applicazione è distribuita a molti clienti.
È "OK" utilizzare lo stesso tasto SALT per la crittografia / decrittografia AES?
Scrivi Salt , ma i tuoi esempi includono dati recuperabili e menzioni un algoritmo di crittografia: AES. Il sale viene solitamente aggiunto agli hash per prevenire collisioni e ridurre il valore delle tavole arcobaleno, come menzionato in altre risposte. Tuttavia, le altre risposte riguardano tutte le password, mentre sembra che tu stia proteggendo i dati recuperabili (SSN, DOB, ecc.). Hash, salting, verificatori password e tabelle arcobaleno non si applicano.
Invece, dovresti usare una IV (Initial Vector) con cifrari simmetrici basati su blocchi e CBC (Cipher Block Chaining) per prevenire la stessa classe di attacco che un Salt protegge contro: attacco in chiaro noto di materiale crittografico.
Ad esempio, Mary e John hanno la stessa data di nascita (ad esempio il 1 maggio 1984). Se hai una chiave master per crittografare tutti i dati, e non usi le IV casuali, chiunque abbia accesso al cryptext nel database può vedere che ENC(Mary_BDATE, Key) == ENC(John_BDATE, Key) .
Tuttavia, con IV casuali univoci, quindi ENC(Mary_BDATE, Key, IV1) != ENC(John_BDATE, Key, IV2) . Qui, l'IV (come un Salt) è memorizzato con il cryptext in chiaro, non deve essere tenuto segreto.
Per inciso, è possibile ottenere lo stesso effetto di un IV univoco anteponendo i dati di testo normale con un blocco Nonce di dimensione. Cioè, ENC(Nonce1||Mary_BDATE, Key) != ENC(Nonce2||John_BDATE, Key) . In questo caso, quando decifri, scarti il Nonce anteposto. Non è necessario memorizzarlo poiché è il primo blocco nel cryptext.
Nota, in entrambi i casi precedenti, il requisito di archiviazione è essenzialmente lo stesso: le lunghezze IV e Nonce devono essere uguali e hanno entrambe la stessa lunghezza della dimensione del blocco. Ci sono alcuni vantaggi nell'usare una IV sulla preposizione del Nonce poiché il testo in chiaro dal passo Decrypt non richiede alcuna manipolazione.
Inoltre, dovresti davvero utilizzare IV esclusivi per tutti i tuoi dati, anche se ritieni che i dati possano essere unici (ad esempio nel caso di SSN). Prima di tutto, l'SSN è un intervallo di valori relativamente piccolo, quindi non ci sono molte scelte per il testo in chiaro che viene crittografato. Ancora più importante, poiché la lunghezza del testo in chiaro è così ridotta, potrebbero esserci alcuni noti attacchi di compromesso chiave su un campo così piccolo. Generalmente, i cifrari a blocchi simmetrici sono costruiti per resistere a questi tipi di attacchi. Tuttavia, quando i dati sono tutti di meno di (e molto meno di) una lunghezza di blocco, c'è solo così tanto che il codice può fare. Aggiungendo un IV casuale, si diffonde la crittografia su due blocchi e si aggiunge più entropia al cryptext. Ciò rende più difficile l'attacco con testo in chiaro noto e vari attacchi chiave.
NON è ok.
Qualcuno può prendere il sale, costruire una tavola arcobaleno e decifrare facilmente tutti i dati da tutti i clienti. L'intero punto di un sale è quello di annullare gli effetti delle tabelle arcobaleno.
Non dovresti nemmeno usare lo stesso sale con un solo cliente. Basta generare un nuovo sale con ogni nuova chiave. È possibile memorizzare il testo crittografato e salare insieme, non è necessario proteggere il sale.
Fornirò un esempio del motivo per cui dovresti utilizzare diversi sali per ogni voce in uno scenario comune di un utente malintenzionato che accede al tuo database.
Dire che sono un malintenzionato che ha appena ottenuto il tuo database. Dal momento che tu, lo sviluppatore attento alla sicurezza, hai cancellato tutte le password, dovrebbe essere difficile per l'hacker ottenere le password e dare agli utenti il tempo sufficiente per cambiare le loro password, giusto?
Non così! Mi è capitato di avere una raccolta piuttosto ampia di hash precalcolati per la lunghezza delle voci n chars a n + k chars (GB e GB di dati .. impiega molto tempo a produrre questo una volta) e proverà tutti i diversi utenti contro di loro .
Hai visto questo arrivo e hai deciso di utilizzare un salt su tutte le voci per l'hashing della password anche se è lo stesso salt.
Non importa, passerò un sacco di tempo a tentare di applicare la password per 1 utente e dopo un paio di giorni o settimane (può essere inferiore se usi le prime 1000 password popolari e solo bruteforce il valore di sale) di provare password diverse ottengo questo: mysaltp@ssw0rd . Ora ricalcolo il mio hashtable con mysalt all'inizio di ogni voce (questo richiede solo fino a quando la prima volta ho calcolato il mio hashtable). Procederò quindi a trovare la password per ogni utente che ha utilizzato una password di lunghezza n in n + k caratteri.
Se usi un sale diverso per ognuno, devo ricalcolare ogni singola combinazione di password tra n chars e n + k chars con l'hash aggiunto ad esso che richiede significativamente più tempo. Inoltre, un uovo marcio (l'utente che ha usato password1234 come password) non guasterà il mazzo e renderà molto più facile ottenere le password.