Quali sono le migliori pratiche (Politica di sicurezza delle applicazioni) per modificare Rijndael Salt, IV, Pass Phrase

AES accetta solo una chiave e una IV. L'IV dovrebbe essere casuale e diverso per ogni crittografia. Semplicemente anteponilo al testo cifrato. Raccomando vivamente di aggiungere l'autenticazione.

Riguardo alle passphrase, le eviterei dove possibile a favore di una semplice chiave casuale. Le chiavi sono semplici sicure ed evitano il costo della derivazione della chiave. Utilizza le password solo quando l'utente deve inserirle.

Quando hai veramente bisogno di una password, un conteggio di iterazioni sufficiente, genera un salt casuale e usa PBKDF2 (o meglio). Questo hashing e salatura è solo lì per compensare le password deboli.
Quando scegliere un nuovo sale nella derivazione della chiave è più complicato. Utilizzare idealmente un nuovo random per ogni crittografia, ma potrebbe essere troppo costoso. A volte puoi riutilizzarli, a volte puoi mettere in cache la chiave, ma dipende dall'applicazione.

Non scriverei direttamente la chiave nel tuo codice sorgente. Il file web.config sembra un posto più appropriato. Non puoi nascondere la chiave, poiché la tua applicazione ne ha bisogno.

Non dovresti implementare la cripto te stesso. Viste le tue domande, ci sono troppe cose che potresti sbagliare. Invece, utilizza una libreria di alto livello come GPG (per crittografare i dati a riposo) o TLS (per i dati in movimento ).

(Se stavi implementando il tuo, non dovrebbe generare chiavi di crittografia da una password ; dovresti utilizzare una chiave true-random. Dovresti scegliere un IV casuale per ciascun messaggio come richiesto dalla modalità. dovrebbe utilizzare l'autenticazione autenticata di crittografia / messaggi . Ma in realtà, non dovresti implementare la tua, poiché c'è troppo da imparare.)

Le risposte esistenti sono ottime, ma ignorano un aspetto importante della tua domanda: migrazione a nuovi IV, modalità e chiavi.

Il modo più semplice per farlo è aggiungere nuove colonne al tuo database. Uno per un ID della chiave di crittografia (un valore univoco per identificare la chiave di crittografia utilizzata), uno per l'algoritmo di crittografia e uno per la IV.

Con la configurazione corrente, si genera un UUID che sarà un riferimento indiretto alla passphrase di crittografia corrente. Questo andrà nella colonna ID chiave per tutti i testi cifrati esistenti. Il nome completo dell'algoritmo, la dimensione del bit e la modalità (ad es. "AES-128-ECB" se quello è quello che stai utilizzando) andranno nella colonna dell'algoritmo. E il tuo IV statico corrente va nella colonna IV.

Per le nuove crittografie, crea una nuova chiave da un CSPRNG (generatore di numeri pseudocasuali crittograficamente sicuro) e un nuovo UUID che identificherà questa chiave. Scegli una modalità appropriata (CBC e CTR sono buone scelte, CBC richiede, a tutti gli effetti, numeri casuali da un CSPRNG mentre CTR richiede solo un nonce unico, che può essere un semplice contatore). Per ogni nuova crittografia, genera un IV esclusivo in base ai requisiti IV per la modalità che hai scelto. Cifra i dati usando la chiave e IV e archivia l'ID della chiave, l'algoritmo, la IV e il testo cifrato nel tuo database.

Per le decrittografie, utilizzare la chiave (indicata con ID), l'algoritmo, IV e il testo cifrato registrati nel database. Se l'ID della chiave corrisponde alla chiave che stai attualmente utilizzando, dovresti anche ricodificare i dati utilizzando la procedura descritta sopra.

Generalmente, crei un nuovo salt ogni volta che re-crittografi tutto ciò che stai proteggendo con il sale (in genere, una password).

Si dovrebbe usare una nuova IV ogni volta in cui si cripta un messaggio. Gli IV duplicati dovrebbero mai essere usati, cioè ogni messaggio cifrato dovrebbe usare un valore IV diverso.

Le passphrase vengono cambiate periodicamente, con la frequenza necessaria per gli utenti. Questo può variare da una volta al mese a una volta all'anno. La maggior parte dei luoghi in cui ho lavorato ci ha richiesto di modificare le nostre passphrase di accesso ogni 90 giorni. Cambiare le passphrase troppo spesso porta a abitudini utente scorrette (ad esempio, usare note post-it per tenerne traccia), mentre non cambiarle abbastanza spesso aumenta la possibilità di una violazione della sicurezza.