Salva i messaggi privati crittografati nel database

Se l'unico modo per eseguire il ripristino della password consiste nel rispondere a una domanda, è possibile crittografare la chiave privata una volta con la password e un'altra volta con la risposta segreta e archiviare entrambe le versioni crittografate nel database. Quindi, se l'utente dimentica la password e utilizza la risposta segreta per il ripristino, è possibile accedere alla chiave privata e ricodificarla con la nuova password (per l'utilizzo normale). Se la risposta segreta viene cambiata, è necessario richiedere la password e quindi la versione crittografata con la risposta può essere rigenerata.

Questo ha (almeno) due problemi. La risposta "segreta" spesso non è così difficile da decifrare. Questo potrebbe essere parzialmente risolto utilizzando PBKDF2 con un numero molto elevato di iterazioni (poiché questa opzione sarebbe usata di rado). Un altro problema è, ovviamente, se per qualche motivo si desidera reimpostare manualmente la password di un utente (cioè ti hanno convinto della loro identità senza conoscere la risposta segreta), allora non sarai in grado di recuperare i messaggi. Ma a seconda di quali compromessi si è disposti a farlo potrebbe essere ancora utile nonostante questi problemi.

encrypted in a database so the information can't be leaked if someone gets access to the database. But I have no idea how to manage the keys.

Ti consiglierò di dare un'occhiata a 2 libri:

Crittografia nel database . Questo libro spiega come gestire le chiavi e gestire i provider di servizi di crittografia. Il codice fornito è Java, ma sembra abbastanza amichevole .NET. Questo libro è finalizzato alla sicurezza, la privacy è irrilevante.

Database traslucidi . Questo libro ha lo scopo di rendere i dati utili e utilizzabili dagli utenti autorizzati, ma inutili per ladri e snoop. Questo libro si rivolge più alla privacy e alla sicurezza un secondo vicino. Ho l'edizione precedente.

The only constant I can come up with is the user's password. But in case the password is lost/forgotten there is no way to access the messages anymore.

Questa risposta risolve il problema di dover essere in grado di recuperare manualmente i messaggi, una volta dimenticata la password. Se hai bisogno di un modo automatico che mantenga l'eccellente livello di sicurezza, potresti essere sfortunato. Questo è per il recupero manuale da parte degli amministratori.

È possibile memorizzare una copia crittografata asimmetricamente delle chiavi generate utilizzando la password.

(Generalmente parlando) La chiave "asimmetrica crittografia per crittografare la chiave generata dalla password" non può essere decodificata.

Quindi è necessario memorizzare la chiave "asimmetrica decrittografia per accedere alla chiave generata dalla password" da qualche parte.

Questo è possibile archiviare su carta o un'unità flash all'interno di una scatola chiusa.

Ciò consente una protezione completa contro l'acquisizione di un accesso di sola lettura, a meno che non trovino i messaggi nel proprio swap o un heap o core dump. Se hai abbastanza RAM e sei abbastanza paranoico, puoi considerare di disabilitare lo swap, e se non usi mai i dump di heap o core, potrebbe anche disabilitare anche quelli.

Qualcuno con lettura-scrittura può essere in grado di cambiare i programmi in modo da memorizzare o inviare in modo permanente i messaggi così come vengono decifrati. Se vuoi essere in grado di combatterlo, dovrai memorizzare il checksum di tutti gli eseguibili (anche il sistema operativo?) E verificare manualmente ogni volta che un checksum cambia che è stato qualcosa che hai fatto, e non un'irruzione. Questo potrebbe darti la possibilità di annullare il danno prima che trapelino molti dati.

Ci sono molte risposte possibili complicate per questo, ma ho intenzione di darti una semplice che non si basa sull'interazione dell'utente diversa dal normale processo di accesso:

Quando un utente effettua l'accesso, genera la chiave di crittografia simmetrica utilizzando la sua password tramite PBDKF2 con una sorta di valore salt.

La prossima parte è una domanda di compromesso sulla domanda di sicurezza su dove archiviare quella chiave. Preferirei archiviarlo come cookie sul computer dell'utente che dura quanto le credenziali di accesso. Dato che la chiave è creata con un salt casuale che viene mantenuto sul server e mai rivelato e la decrittografia può avvenire solo con l'autenticazione, non espone l'utente a attacchi brute-force non in linea sulla propria password.

Infine, non espone l'utente a un maggiore rischio di accesso ai propri dati rispetto a qualsiasi altra sessione di accesso comune. Se il loro computer viene sequestrato e hanno effettuato l'accesso, l'accesso viene raggiunto. Se il loro computer viene bloccato e non sono connessi, l'accesso non viene raggiunto. Se i loro dati sono richiesti da un mandato di comparizione, il loro rilascio non aiuterà a decifrarlo senza la password dell'utente (si spera strong) per generare la chiave appropriata. Inoltre, se ti senti particolarmente snella potresti non riuscire a rivelare il sale a meno che non fosse coperto dalla citazione o le tue macchine siano state effettivamente sequestrate.

A proposito di quell'altra costante privata? Non esiste Non è possibile mantenere una chiave di crittografia segreta da sé e disponibile all'utente per la sostituzione. Puoi tenere la chiave in escrow per decifrare se perdono la password, o se non riescono a perdere la chiave / password. Qualsiasi altra cosa coinvolge complicati cerchi come SSSS e convincere gli amici a garantire che sei tu e dovresti essere in grado di leggere le cose . Quindi devi aver fiducia in loro.

I controlli di sicurezza sono correlati al valore della risorsa che stai proteggendo.

Non ha senso acquistare un blocco sicuro di $ 1.000 per proteggere asset da $ 100.

Nella situazione che descrivi (comunità per studenti locali) direi che anche la semplice crittografia simmetrica sarebbe più che sufficiente.
Solo per controllare:

Memorizzi TUTTE le PII (informazioni personali identificabili) crittografate? Esegui regolarmente test di penetrazione per garantire che il tuo sito sia protetto? Indurisci i tuoi server?

Vorrei investire in questi prima di implementare un meccanismo di crittografia privato-pubblico sofisticato.

Penso che finirai con un sistema che non funzionerà; gli utenti dimenticheranno le chiavi e uccideranno il tuo sistema di supporto.