Vale la pena di crittografia indirizzi e-mail nel database?

https://stackoverflow.com/questions/70450

09-06-2019
|

Domanda

Sto già utilizzando salata di hashing per memorizzare le password nel mio database, il che significa che dovrebbe essere immune rainbow table gli attacchi.

Ho avuto un pensiero, anche se:che cosa succede se qualcuno fa entrare in possesso del mio database?Esso contiene gli indirizzi email.Davvero non posso hash di queste, perché io sarò li utilizza per inviare e-mail di notifica, ecc..

Devo cifrare?

Soluzione

Bruce Schneier ha una buona risposta a questo tipo di problema.

La crittografia non è la soluzione per i vostri problemi di sicurezza.Potrebbe essere parte della soluzione, o potrebbe essere parte del problema.In molte situazioni, la crittografia inizio, facendo peggiorare il problema, e non è a tutti chiaro che utilizza la crittografia è un miglioramento.

Essenzialmente la crittografia e-mail nel database in caso di non è davvero rendere il database più sicuro.Dove sono le chiavi contenute nel database?Cosa permessi dei file sono utilizzati per queste chiavi?È il database accessibili pubblicamente?Perché?Che tipo di account restrizioni sono per questi account?Dove è la macchina di archiviazione, l'accesso fisico a questa scatola?Che cosa circa il login remoto/accesso ssh etc.ecc.ecc.

Quindi credo che si può crittografare i messaggi di posta elettronica, se volete, ma se questo è il grado di sicurezza del sistema e quindi in realtà non fare molto, e sarebbe in realtà fare il lavoro di manutenzione database più difficile.

Naturalmente questo potrebbe essere parte di una vasta politica di sicurezza per il vostro sistema, se è così allora grande!

Non sto dicendo che è una cattiva idea, Ma perché hanno una serratura alla porta da Deadlock R'us costo di $5000, quando si possono tagliare il compensato intorno alla porta?O entrare attraverso la finestra che hai lasciato aperto?O, ancora peggio, si trova la chiave che era rimasto sotto lo zerbino.La sicurezza di un sistema è solo buono come l'anello più debole.Se hanno accesso root poi si può praticamente fare quello che vogliono.

Steve Morgan rende un buon punto che, anche se non sono in grado di comprendere gli indirizzi e-mail, si può ancora fare un sacco di danni (che potrebbe essere mitigato se avevano solo SELEZIONARE l'accesso)

È anche importante sapere che cosa i vostri motivi sono per memorizzare l'indirizzo di posta elettronica a tutti.Potrei andare un po ' in mare con questa risposta, ma il mio punto è che non si ha realmente bisogno di memorizzare un indirizzo e-mail per un account?Il più sicuro dei dati è un dato che non esiste.

Altri suggerimenti

Mi rendo conto che questo è un morto argomento, ma sono d'accordo con Arjan logica dietro a tutto questo.Ci sono un paio di cose che vorrei sottolineare:

Qualcuno può recuperare i dati dal database senza recuperare il codice sorgente (es.SQL injection, di terzi, di db).Con questo in mente, è ragionevole considerare l'utilizzo di un algoritmo di cifratura con una chiave.Anche se, questo è solo un ulteriore misura di sicurezza, non sicurezza...questo è per chi vuole tenere l'email più privato di testo in chiaro, Nella remota possibilità che qualcosa è trascurato durante un aggiornamento, o un utente malintenzionato riesce a recuperare i messaggi di posta elettronica.

IMO: Se avete in programma di crittografia di un messaggio email, archivio salato hash di esso pure.Quindi è possibile utilizzare l'hash per la convalida, il ricambio e l'overhead di un costante utilizzo della crittografia per trovare un'enorme stringa di dati.Quindi sono un privato separato funzione per il recupero e decrittografare i messaggi di posta elettronica quando si ha bisogno di utilizzare uno.

In comune con la maggior parte dei requisiti di sicurezza, è necessario capire il livello di minaccia.

Quali danni può essere fatto se gli indirizzi e-mail sono compromessi?

Qual è la probabilità che ciò accada?

Il danno fatto se gli indirizzi email sono SOSTITUITE potrebbe essere molto maggiore se sono ESPOSTI.Soprattutto se sei, per esempio, utilizzando l'indirizzo email per verificare la reimpostazione della password di un sistema sicuro.

La possibilità che la password sia sostituito o esposto è molto ridotto se si hash di loro, ma dipende da cosa gli altri controlli che avete posto.

Direi che dipende dall'applicazione di database.

Il problema più grande è, dove memorizzare la chiave di crittografia?Perché se l'hacker ha in eccesso di qualcosa di più di tuo DB, tutti i tuoi sforzi sono probabilmente sprecato.(Ricordate, la vostra applicazione sarà necessario che la chiave di crittografia per cifrare e decifrare, così alla fine l'hacker a trovare la chiave di crittografia e utilizzato schema di codifica).

Pro:

Una perdita di DB solo non esporre gli indirizzi di posta elettronica.

Contro:

Crittografia significa perdita di prestazioni.
Di assegnare le azioni del database sarà più difficile, se non impossibile.

Per non rischiare di confondere la crittografia con offuscamento.Comunemente si offusca e-mail per evitare spam.Un sacco di siti web hanno "webmaster _at_ mysite.com" per rallentare crawler da parsing di un indirizzo e-mail come spam potenziale target.Che dovrebbe essere fatto in HTML templates -- non esiste alcun valore di questa operazione persistente di archiviazione del database.

Noi non crittografare nulla a meno che non abbiamo bisogno di tenerlo segreto durante la trasmissione.Quando e dove i dati vengono trasmessi?

Le istruzioni SQL sono trasmessi dal client al server;è che sulla stessa macchina o su una connessione protetta?
Se il tuo server è compromesso, si dispone di una trasmissione accidentale.Se siete preoccupati per questo, allora si dovrebbe forse essere la protezione del server.Avete minacce esterne, come pure le minacce interne.Sono a TUTTI gli utenti (esterni ed interni) correttamente autenticato e autorizzato?
Durante i backup si dispone di un intenzionale di trasmissione a supporto di backup;questo è fatto utilizzando una sicura strategia di backup che consente di crittografare come va?

SQL Server e Oracle (e credo anche gli altri DBs) supporta la crittografia dei dati a livello di database.Se si desidera crittografare qualcosa perché non semplicemente abstract l'accesso a dati che possono essere crittografati sul lato server del database e sinistra all'utente di scegliere se utilizzare i dati crittografati (in questo caso il comando SQL che sarà diverso) o non.Se l'utente desidera utente dati criptati, quindi è possibile configurare il server di database e di tutti i lavori di manutenzione connessi con la gestione delle chiavi è l'utilizzo di standard di DBA strumento, realizzato dal DB venditore e non da te.

Una copia della mia risposta a Che cosa è il migliore e il modo più sicuro per memorizzare indirizzi email utente nel database?, solo per il gusto della ricerca...

In generale concordo con gli altri dicendo che non vale la pena.Tuttavia, io non sono d'accordo che chiunque può accedere al database probabilmente può anche ottenere le chiavi.Questo non è certamente vero per SQL Injection, e potrebbe non essere vero per le copie di backup che sono in qualche modo perso o dimenticato.E mi sento un indirizzo email personale è un dettaglio, in modo che non mi preoccupassi per spam, ma sulle conseguenze personali quando gli indirizzi sono rivelate.

Naturalmente, quando hai paura di SQL Injection, allora si dovrebbe verificare che tali iniezione è vietata.E copie di backup devono essere crittografati se stessi.

Ancora, per alcune comunità online, i membri potrebbero sicuramente non vuoi far sapere agli altri che sono un membro (come relativi alla salute mentale, assistenza finanziaria, medica e sessuale consigli, intrattenimento per adulti, politica, ...).In questi casi, salvare alcuni dati personali possibile e la crittografia di quelli che sono necessari (nota che la crittografia a livello di database non impedisce che i dati che mostrano l'utilizzo di SQL Injection), potrebbe non essere una cattiva idea.Di nuovo:il trattamento di un indirizzo email personale per i dettagli.

Per molti siti di cui sopra non è probabilmente il caso, e si dovrebbe concentrarsi sul divieto di SELECT * FROM tramite SQL Injection, e assicurarsi che i visitatori non possono ottenere in qualche modo a qualcun altro profilo personale o per informazioni di ordine cambiando l'URL.

Vale la pena per crittografare i dati nel Database, non è che rende un po ' più difficile, ma ancora più difficile quando cifrato nel modo giusto per interrompere la filosofia e crittografare i dati sensibili ;)

Si hanno veramente a pesare il tuo caso peggiore scenario di qualcuno ottenere gli indirizzi e-mail, la probabilità che qualcuno l'ottenimento di loro, e il suo sforzo supplementare/tempo necessario per impliement il cambiamento.

@Roo

Ho un po 'd'accordo con quello che stai dicendo, ma non è la pena di crittografare i dati solo per renderlo un po' più difficile per qualcuno per farlo?

Con il tuo ragionamento, sarebbe inutile avere blocchi o allarmi in casa tua, perché possono anche essere facilmente compromessa.

La mia risposta:

Direi che se hai dati sensibili che non si vuole cadere in mani sbagliate, probabilmente si dovrebbe fare è così difficile come si può per un hacker per farlo, anche se non è ancora al 100% infallibile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow