Dividiamolo in due:
Crittografia dei dati dell'utente con la loro password
Certo, perché no, se i dati sono privati. In pratica, il server dovrà gestirlo in testo in chiaro, ma i dati possono essere lasciati crittografati fino a quando l'utente non ha effettuato l'accesso. Sebbene in un forum di messaggi, i messaggi che dovrebbero essere letti da altri utenti non possono essere soggetti a questo trattamento, quindi funziona solo per i messaggi privati (indirizzati a un singolo utente oa un gruppo noto di utenti).
Come sempre, non si desidera utilizzare alcuna password direttamente come chiave, ma eseguirla attraverso alcune funzioni di derivazione della chiave come PBKDF2 . Ciò rallenterà la ricerca della password tramite la forza bruta e darà la possibilità di generare chiavi più lunghe rispetto alla password (nel caso sia necessario).
Per quanto riguarda le modifiche alle password, la prassi abituale consiste nel generare una chiave strong casuale, utilizzata per crittografare i dati e quindi archiviare questa chiave crittografata con (una chiave basata su) la password dell'utente. In questo modo, la modifica della password richiede solo la crittografia della chiave master, non tutti i dati.
Anche se il lato negativo è sempre che se il server è compromesso, può essere configurato per salvare la password dell'utente in testo normale al prossimo accesso, o semplicemente salvare tutti i dati non crittografati.
Cifratura di tutti i dati con la chiave del server
Ecco, mi chiedo quale sia la minaccia prevista? Un attacco software che perde tutti i dati (crittografati) o l'hardware del server viene perso? La protezione da hardware smarrito richiederebbe la crittografia dei dati con una chiave che è non sul sistema stesso , ma forse è stata inserita manualmente. Il modo più semplice per farlo sarebbe utilizzare una soluzione di crittografia a disco intero.
Per quanto riguarda un attacco che in qualche modo perde tutti i dati, ma non consente la modifica del codice stesso, sicuramente, la crittografia con una chiave fissa del server dovrebbe aiutare. Ma è necessario, se i dati sono già crittografati con la chiave dell'utente? Com'è possibile che i dati crittografati perdano ma non la chiave del server, dato che il server avrà bisogno di quella chiave per quasi tutte le operazioni che coinvolgono i dati? Devo dire che non lo so.
(Se stai pensando alle iniezioni SQL, meglio correggere le tue pratiche su quello in cui si trova il problema. D'altra parte, se stai pensando a una vulnerabilità che porta all'esecuzione di codice arbitrario, l'autore dell'attacco ha appena ricevuto la chiave del server anche.)
Combinazione dei due
Il modo ovvio per combinare due chiavi sarebbe quello di crittografare i dati due volte, usando entrambi i tasti, in modo tale che i dati memorizzati siano C = E (K2, (E (K1, P)). Questo è ciò che accadrebbe nel fine se si memorizzano i dati crittografati su un'unità crittografata, ma è un po 'uno spreco o lavoro.
Un altro modo sarebbe quello di ricavare la chiave di crittografia effettiva dalle due chiavi (server e utenti) usando un KDF (di nuovo). Anche se con input dall'aspetto casuale, penso che potresti farla franca combinando due chiavi a lunghezza fissa con un hash strong come SHA-256, quindi C = E (H (K1, K2), P).