Voglio crittografare determinate voci in un database. È un buon piano?

Question

Voglio crittografare determinate voci in un database. È un buon piano?

#1 da (1 voti)
#2 da (1 voti)

2

Sto lavorando su un'app Web e voglio offrire agli utenti l'opzione di "crittografare" il loro account. Ciò non crittograferebbe tutto ciò che è relativo a loro nel database. Solo alcuni campi critici.

Ho già letto l'ottima risposta di DWs sul problema ( link ), e nonostante tutto ciò , Voglio farlo, a causa di alcune differenze chiave:

Prima di tutto: nessuno dei dati che sto crittografando è di fondamentale importanza. Questa è un'app giocattolo, per lo più per me, da cui imparare e forse mettere su un curriculum. Non ci sono utenti reali.

In secondo luogo, sto usando i framework e le tecnologie esistenti. È un'app Django, quindi ho già un sacco di protezioni e alcune impostazioni predefinite sane come la protezione CSRF. Sono consapevole che non è la polvere magica di Pixie che renderà sicura la mia applicazione, ma "... sto ancora imparando e facendo il meglio che posso."

Con tutto ciò, ecco come voglio implementarlo:

L'utente registra un account. Durante la registrazione, viene offerta l'opzione per la crittografia dell'account e una password separata da utilizzare per i campi crittografati.
Gli account crittografati hanno un bool encrypted , impostato su true. Questa è l'unica differenza negli account sul back-end.
Quando l'utente esegue il login, se encrypted=True , viene visualizzato un prompt per consentire loro di digitare la propria password, che è archiviata nella memoria lato client, e utilizza la crypto JS del browser (lo so, lo so ... ) per crittografare / decodificare le voci.

Voglio assicurarmi che nessuno tranne l'utente possa leggere le proprie voci e questo sembra un modo semplice per raggiungere questo obiettivo. Ma siccome questa è la sicurezza, c'è probabilmente un milione di modi per farlo in modo sbagliato, e non c'è un modo perfetto per farlo, quindi sono molto interessato alle opinioni di qualcuno più esperto di me e sarei davvero grato se qualcuno potesse evidenzia potenziali vulnerabilità o aree in cui le cose possono andare storte.

client-side cryptography encryption web-application databases

posta Alexskc 14.06.2016 - 06:13

fonte

2 risposte

1

In primo luogo, su HTTP non c'è modo di farlo in modo sicuro.
E quando includi una connessione TLS (a.k.a. HTTPS), perché decrittografare al browser?
Sembra il posto peggiore per farlo.

Se la riservatezza è davvero necessaria, utilizzare le tecnologie di crittografia appropriate come PGP / GPG e far decodificare / crittografare l'utente sulla propria macchina. Tutto quello che fai è salvarlo.
O se è richiesta la convenienza criptare / decrittografare sul server, si deve sempre fidarsi del server in ogni caso quindi nessuna vera differenza lì.

Ti suggerisco di rileggere prima la pagina che hai scontato come fonte e cercare di capire in un modo migliore perché la gente dice che la crittografia non è utilizzata in questo modo.

risposta data 14.06.2016 - 09:53

fonte

Leggi altre domande sui tag client-side cryptography encryption web-application databases

Interazione tra registratore di cassa e terminale di carta Ciclo di vita del certificato CA.

score 1 · Accepted Answer

Dato che tu dici che questa non è una vera applicazione, qui commenterò solo un paio di punti. Il primo è un dettaglio di implementazione che potresti aver già considerato, il secondo è più di un teorico "vale la pena farlo?" domanda.

1. Cambia password.

Generalmente è considerata una buona pratica richiedere agli utenti di cambiare la propria password ogni tanto. Se questa password è stata utilizzata direttamente per ricavare la chiave utilizzata per proteggere i propri dati, avrai un mondo di feriti davanti a te: dovrai decrittografare i loro dati memorizzati con la vecchia chiave e poi cifrarla con la nuova chiave. Che schifo. Cicli di macchina sprecati e potenziale vaso di miele per un attaccante, dal momento che devi tornare al testo in chiaro per farlo.

Uno schema migliore sarebbe quello di assegnare all'utente una chiave casuale (la loro chiave di crittografia dei dati o DEK) al momento della registrazione, e crittografare quella chiave con una chiave derivata dalla loro password (i loro Chiave di crittografia chiave o KEK). Il DEK viene utilizzato per crittografare i dati effettivi, il KEK viene utilizzato per proteggere il DEK e non viene mai memorizzato. Quindi, quando cambiano la loro password, stanno semplicemente cambiando il KEK: il DEK non cambia, quindi non è necessario aggiornare i dati memorizzati, a parte il valore crittografato del DEK, che ora è crittografato con il nuovo KEK .

2. È una buona idea?

Sì. Assolutamente. La crittografia dei dati effettivi in un database protegge i dati da alcuni vettori di minacce che gli approcci meno granulari non coprono. Ad esempio, né un file system crittografato per l'archiviazione delle tabelle del database né la crittografia della tabella del database protegge da un amministratore di database non autorizzato con la possibilità di emettere una query select * from customers; . Se i dati stessi sono protetti e le chiavi sono sicure (una considerazione importante), tutto ciò che un utente malintenzionato può ottenere sono i dati crittografati.

Detto questo, ci sono alcuni aspetti da considerare. Ad esempio, se si crittografano i SSN dei clienti nel proprio database, ciò avrà un impatto sui dipendenti del call center che ordinariamente chiedono ai clienti il loro SSN per poterli autenticare? Inoltre, cosa succede quando i dati del tuo sistema devono essere esportati per essere inviati a un partner commerciale, che non ha accesso alle tue chiavi?

Nessuno di questi problemi è un motivo per non implementare la sicurezza nelle tue applicazioni, ma devi essere consapevole che non è un'impresa banale.