Come crittografare i dati sensibili nel database di un'app Web?

L'approccio generalmente accettato è simile a quello suggerito da AndrolGenhald in una risposta precedente ma con alcuni miglioramenti.

È possibile crittografare individualmente i dati di ciascun utente, utilizzando una chiave derivata dalla propria password. Fai non , tuttavia, desideri utilizzare la password direttamente come chiave. È un processo multi-step, come segue.

1) Si genera una chiave casuale, utilizzando un CSPRNGm, e si usa questa chiave casuale per crittografare i dati dell'utente. È possibile creare una nuova chiave casuale diversa per ciascun utente. Questo è chiamato DEK o chiave di crittografia dei dati.

2) Prendi la password dell'utente ed eseguila attraverso un PBKDF (come PBKDF2, bcrypt o scrypt) usando un fattore di lavoro ragionevolmente alto o un numero di iterazioni e un salt casuale per creare una seconda chiave, la chiave KEK o -chiave di crittografia. Quindi si crittografa il DEK utilizzando KEK e si memorizzano il DEK crittografato e il sale nel database.

Quindi, quando l'utente esegue l'accesso, si utilizza la propria password e il sale dal database per rigenerare il KEK, che è possibile utilizzare per decrittografare il DEK, che è possibile utilizzare per decrittografare i dati.

Ora, quando l'utente cambia la propria password, non è più necessario decrittografare e crittografare nuovamente tutti i propri dati, ma semplicemente utilizzare la nuova password (e un nuovo salt) per generare un nuovo KEK e ricodificare il DEK usando questo nuovo KEK.

Puoi:

1. Ricodifica tutto ogni volta che un utente cambia nome utente o password
2. Genera una chiave casuale per ogni utente che usi per crittografare i dati, quindi crittografa questa chiave con la password dell'utente (o nome utente + password)

Non consiglierei di usare solo il nome utente come chiave, anche se memorizzi il nome utente crittografato (che sembra un po 'estremo), i nomi utente in genere non sono considerati segreti.

Se si desidera crittografare le informazioni dell'utente, che è memorizzato in un database, consiglierei di non memorizzare la chiave per decodificare i dati nello stesso database. Cripterei i contenuti con un segreto nascosto altrove con criteri di accesso più rigidi. In questo modo l'utente malintenzionato deve avere accesso sia al tuo archivio chiavi sia al tuo database per ottenere tali dati. Questo allarga la superficie di attacco.