Vale la pena crittografare gli indirizzi e-mail nel database?

Sto già usando l’ hashing salato per archiviare le password nel mio database, il che significa che dovrei essere immune agli attacchi dei tavoli arcobaleno .

Ho avuto un pensiero, però: cosa succede se qualcuno si impossessa del mio database? Contiene gli indirizzi email degli utenti. Non posso davvero cancellarli, perché li userò per inviare email di notifica, ecc.

Dovrei crittografarli?

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

La crittografia non è la soluzione ai tuoi problemi di sicurezza. Potrebbe essere parte della soluzione o potrebbe essere parte del problema. In molte situazioni, la crittografia inizia a peggiorare il problema, e non è affatto chiaro che l’uso della crittografia sia un miglioramento.

In pratica, la crittografia delle e-mail nel database “nel caso in cui” non rende davvero il database più sicuro. Dove sono archiviate le chiavi per il database? Quali permessi dei file vengono utilizzati per queste chiavi? Il database è accessibile pubblicamente? Perché? Che tipo di restrizioni sull’account sono in vigore per questi account? Dove si trova la macchina, chi ha accesso fisico a questa scatola? Che dire dell’accesso remoto / accesso ssh, ecc. Ecc. Ecc.

Quindi suppongo che puoi cifrare le e-mail se vuoi, ma se questa è l’ quadro della sicurezza del sistema, in realtà non sta facendo molto e renderebbe il compito di mantenere il database più difficile.

Naturalmente questo potrebbe far parte di una politica di sicurezza estesa per il tuo sistema – se è così grande!

Non sto dicendo che sia una ctriggers idea – Ma perché avere un lucchetto sulla porta di Deadlocks’R’us che costa $ 5000 quando possono tagliare il compensato attorno alla porta? Oppure entra dalla finestra che hai lasciato aperta? O ancora peggio trovano la chiave che è stata lasciata sotto lo zerbino. La sicurezza di un sistema è valida quanto il collegamento più debole. Se hanno accesso come root, possono fare praticamente ciò che vogliono.

Steve Morgan fa un buon punto sul fatto che, anche se non riescono a capire gli indirizzi e-mail, possono comunque fare molti danni (che potrebbero essere mitigati se avessero solo accesso SELECT)

È inoltre importante sapere quali sono le ragioni per cui memorizzi l’indirizzo email. Potrei essere un po ‘esagerato con questa risposta , ma il mio punto è che hai davvero bisogno di memorizzare un indirizzo email per un account? I dati più sicuri sono dati che non esistono.

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

Che danno può essere fatto se gli indirizzi e-mail sono compromessi?

Qual è la possibilità che accada?

Il danno fatto se gli indirizzi e-mail sono SOSTITUITI potrebbe essere molto più grande di quelli che sono ESPOSTI. Soprattutto se, ad esempio, utilizzi l’indirizzo email per verificare il ripristino della password su un sistema sicuro.

La possibilità che le password vengano sostituite o esposte è molto ridotta se le si blocca, ma dipende da quali altri controlli sono in atto.

Mi rendo conto che questo è un tema morto, ma sono d’accordo con la logica di Arjan dietro a questo. Ci sono alcune cose che vorrei sottolineare:

Qualcuno può recuperare i dati dal database senza recuperare il codice sorgente (ad es. SQL injection, db di terze parti). Con questo in mente, è ragionevole considerare l’utilizzo di una crittografia con una chiave. Anche se, questa è solo una misura aggiuntiva di sicurezza, non la sicurezza … questo è per qualcuno che vuole mantenere l’e-mail più privata del testo in chiaro, nella remota possibilità che qualcosa venga trascurato durante un aggiornamento o che un utente malintenzionato riesca a recuperare il messaggi di posta elettronica.

IMO: Se hai intenzione di crittografare una email, memorizza anche un hash salato. Quindi è ansible utilizzare l’hash per la convalida e risparmiare l’overhead di utilizzare costantemente la crittografia per trovare una grande quantità di dati. Quindi disporre di una funzione privata separata per recuperare e decrittografare le e-mail quando è necessario utilizzarne una.

Direi che dipende dall’applicazione del tuo database.

Il problema più grande è, dove memorizzi la chiave di crittografia? Perché se l’hacker ha qualcosa in più del tuo DB, tutti i tuoi sforzi sono probabilmente sprecati. (Ricorda, la tua applicazione avrà bisogno della chiave di crittografia per decifrare e crittografare, quindi alla fine l’hacker troverà la chiave di crittografia e utilizzerà lo schema di crittografia).

Pro:

  • Una perdita del tuo DB non esporrà gli indirizzi e-mail.

Contro:

  • Crittografia significa perdita di prestazioni.
  • L’assegnazione delle azioni del database sarà più difficile se non imansible.

Non confondere accidentalmente la crittografia con l’offuscamento. Normalmente offuschiamo le e-mail per prevenire lo spam. Molti siti Web avranno “webmaster _at_ mysite.com” per rallentare i crawler dall’analizzare l’indirizzo email come potenziale bersaglio di spam. Questo dovrebbe essere fatto nei template HTML – non c’è alcun valore per farlo nella memoria persistente del database.

Non criptiamo nulla a meno che non abbiamo bisogno di tenerlo segreto durante la trasmissione. Quando e dove verranno trasmessi i tuoi dati?

  1. Le istruzioni SQL vengono trasmesse da client a server; è sulla stessa scatola o su una connessione sicura?

  2. Se il tuo server è compromesso, hai una trasmissione involontaria. Se sei preoccupato per questo, allora dovresti forse proteggere il tuo server. Hai minacce esterne e minacce interne. Tutti gli utenti (esterni e interni) sono correttamente autenticati e autorizzati?

  3. Durante i backup si ha una trasmissione intenzionale su un supporto di backup; questo è fatto usando una strategia di backup sicura che cripta come va?

Sia SQL Server che Oracle (e credo anche altri DB) supportano la crittografia dei dati a livello di database. Se si desidera crittografare qualcosa perché non si deve semplicemente astrarre l’accesso ai dati che potrebbero essere crittografati sul lato server del database e lasciare l’utente scegliere se utilizzare i dati crittografati (in questo caso il comando SQL sarà diverso) oppure no. Se l’utente desidera utilizzare i dati crittografati, può configurare il server del database e tutte le attività di manutenzione connesse alla gestione delle chiavi vengono eseguite utilizzando lo strumento DBA standard, creato dal fornitore del database e non da te.

Una copia della mia risposta a Qual è il modo migliore e più sicuro per archiviare gli indirizzi email degli utenti nel database? , solo per il gusto della ricerca …


In generale sono d’accordo con gli altri dicendo che non ne vale la pena. Tuttavia, non sono d’accordo sul fatto che chiunque possa accedere al tuo database possa probabilmente anche ottenere le tue chiavi. Questo non è certamente vero per SQL Injection e potrebbe non essere vero per copie di backup che sono in qualche modo perse o dimenticate. E sento che un indirizzo email è un dettaglio personale, quindi non mi interesserebbe lo spam ma le conseguenze personali quando gli indirizzi vengono rivelati.

Ovviamente, quando hai paura di SQL Injection, assicurati che tale iniezione sia proibita. E le copie di backup dovrebbero essere crittografate.

Tuttavia, per alcune comunità online i membri potrebbero non volere che gli altri sappiano di essere membri (come quelli relativi all’assistenza sanitaria mentale, all’aiuto finanziario, alla consulenza medica e sessuale, all’intrattenimento per adulti, alla politica, …). In questi casi, archiviare il minor numero ansible di dati personali e crittografare quelli necessari (notare che la crittografia a livello di database non impedisce la visualizzazione dei dettagli mediante SQL Injection), potrebbe non essere una ctriggers idea. Ancora: tratta un indirizzo email come tale dettaglio personale.

Per molti siti, questo non è probabilmente il caso, e dovresti concentrarti sul divieto di SELECT * FROM tramite SQL Injection e assicurarti che i visitatori non possano in qualche modo accedere al profilo personale di un altro o alle informazioni sull’ordine cambiando l’URL.

Vale la pena di crittografare i dati nei database, non è renderlo un po ‘più difficile, ma è molto più difficile quando è crittografato nel modo giusto, quindi basta con la filosofia e crittografare i dati sensibili;)

Devi davvero soppesare il tuo caso peggiore di qualcuno che ottiene quegli indirizzi email, la probabilità che qualcuno li ottenga e il tuo sforzo / tempo extra necessari per imporre il cambiamento.

@Roo

Sono un po ‘d’accordo su quello che stai dicendo, ma non vale la pena criptare i dati solo per rendere un po’ più difficile per qualcuno ottenerlo?

Con il tuo ragionamento, sarebbe inutile avere serrature o allarmi in casa, perché possono anche essere facilmente compromessi.

La mia risposta:

Direi che se hai dati sensibili che non vuoi cadere nelle mani sbagliate, probabilmente dovresti farlo il più difficile che puoi per un hacker per ottenerlo, anche se non è al 100% infallibile.