Cifra i dati memorizzati in un database

Question

Cifra i dati memorizzati in un database

#1 da (3 voti)
#2 da (0 voti)

3

Recentemente ho parlato con un potenziale cliente che vuole creare un database che contenga dati abbastanza sensibili. Uno dei suoi requisiti chiave è che i dati archiviati verranno crittografati in modo tale che solo l'utente sarà in grado di accedervi. Anche se ci sono certamente alcuni svantaggi, ho pensato a come avrei potuto ottenere questo risultato e ho trovato il seguente approccio:

Quando viene creato un utente, sto creando per lui una coppia di chiavi pubblica / privata. La chiave privata verrà crittografata simmetricamente con la password dell'utente. Tutti i dati che sono memorizzati nel database (molto probabilmente tranne il timestamp - e ovviamente l'id) sono cifrati preventivamente con la chiave pubblica. Quando l'utente accede la password verrà utilizzata per decodificare la chiave privata, che a sua volta può essere utilizzata per decrittografare i dati dal database durante la lettura. Tutte le operazioni di decodifica e decodifica possono avvenire in modo trasparente nel livello di accesso ai dati.

Ci sono alcuni importanti svantaggi da affrontare qui:

Dovremo rimuovere e crittografare la chiave privata quando l'utente desidera cambiare la sua password
Se l'utente perde la sua password non saremo in grado di ricostruire i dati
Sia la chiave privata che la password dell'utente devono essere temporaneamente salvate in testo
Ogni volta che sospettiamo che una chiave privata sia stata danneggiata (nel senso di furto) dovremo ricodificare tutti i dati degli utenti

e, naturalmente, un po 'di più che non mi è ancora arrivato.

Il primo problema è scomodo per noi, ma può accadere in modo trasparente all'utente, quindi nessun grosso problema.

Il secondo è un po 'più complicato. Non vogliamo che l'utente perda i suoi dati, ma dovremo presumere che l'utente perderà la sua password (la memorizzazione e / o l'uso di una password fissa non sono opzioni per ovvi motivi - mai). Una possibile soluzione sarebbe quella di creare una passphrase molto strong (più di 30 caratteri) che verrà utilizzata per crittografare un backup della chiave privata. Questo potrebbe essere inviato all'utente tramite posta ordinaria o simili. L'utente può usare questo per ripristinare i suoi dati se ha dimenticato la sua password.

Ho una brutta sensazione di no. 3, ma al momento non ho un'idea migliore.

Il quarto problema è di nuovo scomodo per noi e potrebbe richiedere del tempo, ma non dovrebbe essere un grosso problema. L'unico problema è il fattore umano qui. Avremmo bisogno che l'utente effettui il login per eseguire la re-encryption e non sarebbe in grado di farlo automaticamente.

Esistono gravi difetti a questo proposito, in particolare per quanto riguarda la sicurezza dei dati? E 'comunque una buona idea?

encryption databases

posta Paul K 14.08.2015 - 14:02

fonte

2 risposte

Leggi altre domande sui tag encryption databases

È una cattiva idea inoltrare un'e-mail sospetta con un allegato - anche a un indirizzo sicuro per l'analisi? I motori di ricerca forniscono l'indirizzo IP del ricercatore ai siti che appaiono nella ricerca? [chiuso]

score 3 · Answer 1

One of her key requirements is, that the data stored will be encrypted in a way that only the user will be able to access it.

L'unico modo per garantirlo veramente è che la chiave di crittografia risieda sul client, sotto il controllo dell'utente. Questo introduce (almeno) due problemi -

Avere un client abbastanza spesso per supportare la gestione delle chiavi e la decrittografia
Gli utenti perderanno le loro chiavi e, corrispondentemente, i loro dati

Il primo tende a escludere le applicazioni basate su browser (anche se sono sicuro che qualcuno, da qualche parte, è stato abbastanza intelligente da trovare un modo per farlo). Il secondo è un'implicazione inevitabile del requisito e potrebbe essere accettabile per gli utenti (un utente con requisiti di segretezza sufficientemente elevati potrebbe preferire la perdita dei dati rispetto a quelli compromessi).

Le protezioni che hai escogitato - utilizzando la password dell'utente per proteggere la chiave - proteggi l'utente da te solo se sei onesto. Se sei non onesto, puoi catturare la password quando sbloccano la chiave o acquisire la chiave sbloccata quando la usano. O forse sei onesto, ma dietro di te c'è un agente del governo con un mandato e / o una pistola. In ogni caso, se intendi veramente "crittografato in un modo che solo l'utente sarà in grado di accedervi", l'utente deve essere il custode della chiave.

(Ora - in effetti - se fornisci il client, allora devono aver fiducia che non lo hai backdoor per catturare la loro chiave, i loro dati, ecc. ecc. Ma teoricamente , dal hanno il cliente in mano, possono analizzarlo e tentare di rilevare tale comportamento scorretto da parte tua - proprio come i fornitori di anti-virus e i risponditori di incidenti forensi analizzano il codice per vedere cosa sta facendo sotto il cofano. Ciò migliora la loro sicurezza su ciò che sarebbe essere se la chiave è archiviata / usata lato server. Realisticamente poche persone hanno le capacità per farlo, e ancor meno hanno la motivazione, ma il fatto che sia possibile si traduce nella percezione che il client può essere considerato più affidabile del server in questo scenario)

score 0 · Answer 2

Se hai intenzione di percorrere questa strada, una chiave di derivazione (KDF) dalla password degli utenti potrebbe essere la strada da percorrere. In questo modo le chiavi di crittografia vengono generate dall'input dell'utente in modo da non dover memorizzare alcuna chiave. Tuttavia, questo problema si verifica anche nel caso in cui l'utente non possa ricordare la sua password, i dati andranno persi e anche i KDF possono avere problemi di implementazione.

altro su KDF's

Detto questo, perché seguire questa strada? La maggior parte dei database principali ha la capacità di crittografare a riposo e crittografare i propri backup. Se fai attenzione ad attuare una sicurezza adeguata nel tuo sito web, rete e database, gli utenti finali non dovranno preoccuparsi di perdere i loro dati o di perdere i loro dati agli hacker.